[rock-user] Re: Distributions vs kernel development

Hi,

On: Sun, 09 May 2004 13:40:44 -0500,
    "J. Ryan Earl" <[email protected]> wrote:

> >Gentoo has no support for custom modifications not even thinking about
> >a way to group such custom modifications / build configuration into a
> >well defined way to form a distribution. 
> >
> Wow, have you ever used Gentoo actually?

Yes, and from time to time I look into an ebuild - what I see usually
hurts my eyes.

>  Gentoo is a Meta-Distribution: 
> a distribution that describes itself.  Purely by -definition- you can 
> modify it in any way you want.  There is no limit to how you can modify 
> it, I'm not sure what gives you this idea.

I can modify _any_ source in the way I want. There is nothing META
needed. And by maintaining my own copy I have a fork. There does not
seem to be much Meta in Gentoo - I just see a source distribution.

You still did not got it? Sure I can also maintain a copy of SuSE
SRPMs and mess in it like I want, but the next time you have to merge
carefully. In ROCK Linux (a distribution build kit) you can cleanly
interfact with the build system and all the packages build in a clean
- well defined fashion and store those modification in a target -
where multiple of this targets can nicely coexist.

> Custom groups?  Group is such a vague term, but I'll give an example of 
> a "custom group."  Say you have an identical set of 50 mcahines each 
> with their own harddrives.  You can maintain your own snapshop of Gentoo 
> (ie portage) on your own rsync server in which you have your own sandbox 
> in which you test and validate updates before pushing them to the 
> "group" of 50 machines in a prebuilt binary package format.

Which is a seperated tree like a fork of Gentoo.

> Just read this snippet from the sample make.conf:

Humans long ago learned spoken and written words to abstract thing? I
shoudl really try to guess what those random variables are good for
(which ahs nothing to do with generically customizing a distribution)?

> # FEATURES are settings that affect the functionality of portage. Most of
> #     these settings are for developer use, but some are available to non-
> #     developers as well.
> #
> #  'autoaddcvs'  causes portage to automatically try to add files to cvs
> #                that will have to be added later. Done at generation times
> #                and only has an effect when 'cvs' is also set.

?

> #  'buildpkg'    causes binary packages to be created of all packages that
> #                are merged.

Wow.

> #  'ccache'      enables ccache support via CC.

/me too - no problem

> #  'cvs'         feature for developers that causes portage to enable all
> #                cvs features (commits, adds) and all USE flags in SRC_URI
> #                will be applied for digests.

?

> #  'digest'      autogenerate a digest for packages.

??

> #  'distcc'      enables distcc support via CC.

Wow.

> #  'fixpackages' allows portage to fix binary packages that are stored in
> #                PKGDIR. This can consume a lot of time. 'fixpackages' is
> #                also a script that can be run at any given time to force
> #                the same actions.

What the hell is this for?

> #  'keeptemp'    prevents the clean phase from deleting the temp files ($T)
> #                from a merge.

? If this is not to remove an extracted and tried to build tarball we
have this "feature" too ...

> #  'keepwork'    prevents the clean phase from deleting the WORKDIR.

?

> #  'noauto'      causes ebuild to perform only the action requested and
> #                not any other required actions like clean or

?

> #  'noclean'     prevents portage from removing the source and temporary 
> files
> #                after a merge -- for debugging purposes only.

?

> #  'nostrip'     prevents stripping of binaries.

Wow - we have this, too (have I mentioned in a cool "make menuconfig"
style GUI?). This nothing to do with customizing a distribution.

> #  'notitles'    disables xterm titlebar updates (which contain status 
> info).

Aha ...

> #  'sandbox'     enable sandbox-ing when running emerge and ebuild

Uhm.

> #  'strict'      causes portage to react strongly to conditions that
> #                have the potential to be dangerous -- like missing or
> #                incorrect Manifest files.

Well ... what is it for?

> #  'userpriv'    allows portage to drop root privleges while it is compiling
> #                as a security measure, and as a side effect this can remove
> #                sandbox access violations for users.

Interesting.

> #  'usersandbox' enables sandboxing while portage is running under userpriv.
> #                unpack -- for debugging purposes only.

Aha.


I have not seen a single thing that has s.th. to do with creating a
custom distribution. This involves:

- possibility to interact with the build process of every package to
spread files to different places, modify file content, config files,
etc.

- possibility to add patches to every package - in a well defines
manner outside of the main package repository (after all this is under
source control and not intended by 3rd parties to be messed with)

- possiblity to change the whole build process to do s.th. totally
different

- possiblity to change the output format like custom FLASH creation,
custom boot image creation (such as live-cd) and so on.

This is all possible within ROCK Linux.

> That's not right either, you can have your own sandbox (see above) in 
> Gentoo in additional to custom CFLAGS and USE flags that customize which 
> packages play with other packages.

Yeah - with this non-existing sandbox or so I also would like to have
an own implementation. In fact ROCK already ships a useful and
full-featured one ...

> >And when you read some ebuild scripts you find
> >the ROCK Linux automatics and tag based ASCI package description
> >format very pleasant, e.g.:
> >
> You can pimp ROCK without trying to knock Gentoo; Gentoo is quite 
> powerful, well supported, and easy to extend customize.

Sure Gentoo is s.th. - and why does all those Gentoo freaks always has
to bash everything else? After all I just (just!) wanted to mention
that there s.th. else then Fedora Core, Suse, Debian or Gentoo. But
somehow those Gentoo frekas always freaks up ofr this.

Sincerely yours,
  René Rebe
    - ROCK Linux stable release maintainer

--  
René Rebe - Europe/Germany/Berlin
  [email protected] [email protected]
http://www.rocklinux.org http://www.rocklinux-consulting.de