Re: Improved Build Process

2009-12-26 Thread Sean Kennedy
Hi David.

As a person who has worked with the OpenBSD process for easily 12+ years, and
longer with a Variety of other platforms;
a Wholesale Change such as you are recommending is going to be negatively
looked at.

Not that what You are typing about is not possible; In fact having a Slice for
the /usr/obj  folder makes for faster turnaround when doing sysgens. I my case
I have to re-read existing documentation once in a while to keep up-to-date on
-even- maintaining -stable or -current... And OpenBSD is pretty simple.

But the scope of what you are considering / suggesting is a bit much.

One of the firstfold reasons that OpenBSD has become a Unix that I appreciate,
is due to the diligence of the development principals in using ASAP rules (As
Simple As Possible) since this establishes two things: Clarity and
Correctness.

As for /usr/ports  well, thats because we live in an Open Source and Free
World.
If something needs improvement, sit-down, code, and pay it forward by sending
info to the Principals of the Port in Question.

Being new to anything is not an excuse, it means you need to sit down and read
the manuals, ask some misc@ questions, and when you feel there is something to
contribute -- contribute.

Its a Shut-Up and Hack thing, not a How We All can make -this- Unix-Based
Operating System look like the SuSE build for s390.

-sean

 Subject: Improved Build Process

 I am somewhat new to OpenBSD but not systems and/or
 systems programming as a whole.  Please excuse any errors

 Thanks for reading this.  I hope it is considered valuable.


_
Windows Live: Keep your friends up to date with what you do online.
http://go.microsoft.com/?linkid=9691815



Re: Improved Build Process

2009-12-26 Thread Tomas Bodzar
Ugh sorry that I don't read it till end, but even first part looks
ugly for me. No, I'm not a programmer, I'm just fuc. newbie in
programming because first years I focused on learning and using all
types of systems so that I can be good sysadmin (maybe) later. I end
with my discoveries on OpenBSD because it's clean, intelligent,
stable, secure, has well documentation and its developers really know
what they are doing and why they are doing it so. From time of start
with OpenBSD I just cry when I use some other systems because they
aren't so good even if they are better for some use.


OpenBSD has very good filesystem hierarchy
http://www.openbsd.org/cgi-bin/man.cgi?query=hierapropos=0sektion=0manpath
=OpenBSD+Currentarch=i386format=html
, not something like mmm this can be here in /usr/bin, this will be in
/usr/local/bin. this will be in /opt, this will be here and here and
here and here and ou I'm a developer so place something here (eg.
directly to /) just because I'm developer and I want to reinvent wheel
like on other systems. Eg. I like OpenSolaris too, but its hierarchy
is quite crazy for me in some cases
http://docs.sun.com/app/docs/doc/819-2252/filesystem-5?l=ena=view
it's because of mix of System V and BSD and some other additions
sometimes to find something is like adventure game :-)

Reagarding CVS... OpenBSD use it's own AnonCVS and I think that it
works well for its purpose. You can read in-deep info here
http://www.openbsd.org/papers/anoncvs-paper.ps , quite old, but I read
it last week and it was very descriptive and useful for me.

Style of kernel is described well here
http://www.openbsd.org/cgi-bin/man.cgi?query=styleapropos=0sektion=0manpat
h=OpenBSD+Currentarch=i386format=html

There are manuals how to build ISO either for CD-ROM or USB flash disk
so you don't need something special. Just read FAQ and if you want you
can make shell scripts for those purposes or write some app with
language which is in base and if it will be ok maybe it will end in
base system. Eg. http://www.openbsd.org/faq/faq14.html#flashmemLive

So in short there are good tools available right now and system is
prepared too. In fact it's quite boring in production because it just
works and works and works and works so you don't need to fight fight
it like with other systems (of course that bugs are even in OpenBSD,
but main source of bugs with OpenBSD is between keyboard and chair).
Maybe you have good idea in some points, but it's not good idea to
have too much multiple tools on one task. I tested DragonflyBSD right
now and they have 5(!) tools for packgae installation anyway no one
from them was able to install Xorg correctly (maybe problem of VM). I
don't think that this mess will help somehow to sysadmin, developer or
user.

On Sat, Dec 26, 2009 at 9:48 PM, David Shuman d.shu...@att.net wrote:
 I am somewhat new to OpenBSD but not systems and/or
 systems programming as a whole. B Please excuse any errors
 I may have made in my observations and desires. B Please
 also feel free to pick and choose between the aspects of
 this that appear to be valuable. B (I can provide my versions
 of the scripts indicated below if that is of assistance however
 many of these may be obvious in their content to experienced
 OpenBSD people that follow this group. These scripts may be
 missing some desirable error checking code)

 Security is one of the stated objectives of OpenBSD yet the current
 build process appears to be difficult to secure largely because the
 build directories are numerous and mixed in with directories for
 general machine operation. (also difficult to backup/restore if the
 user desires to maintain multiple machine configurations using this
 process. B While the content of these directories is publicly
 available, the specific contents for each configuration is NOT
 as are the security requirements to protect the contents for EACH
 SPECIFIC configuration. B The directories for many of the operations
 appear to be hard coded in some of the make scripts to specific
 directories. B I even experienced indications that the directory /CVS
 seems to be assumed to be a repository that can not be used for
 checkout, in my various attempts to do this with the existing code base.

 My suggestion for improvement and simplification include maintaining
 a completely separate directory structure(s) for the build process
 from normal machine operation. See below for hierarchy and
 description:

 /bld B  B  B  B  B  B  B  B  B  B  B root directory for build operation
 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B (no data this
directory/mount only other
 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  directories except for
the
 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  shell scripts
and logs)
 /bld/sh B  B  B  B  B  B  B  B  shell scripts to complete various build
processes
 B  B  B  B  B  B  B  B  B  B  B  B  B  B  B  (see list below)
 /bld/sh/log B  B  B  B  B  B location to store logs from