Re: Distributions vs kernel development

From: J. Ryan Earl
Date: Sun May 09 2004 - 13:46:13 EST


Rene Rebe wrote:

Hi,

On: Sun, 9 May 2004 10:59:48 +0200 (CEST),
Grzegorz Kulewski <kangur@xxxxxxxxxx> wrote:



You have binary packages in Gentoo so you can build once for many machines. All you need is to add one option to /etc/make.conf.



But the last time I took a look not even an installer or such.

When was the last time you looked? You mean no GUI, braindead installer?

+
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? 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.

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.

Just read this snippet from the sample make.conf:

# 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.
# 'ccache' enables ccache support via CC.
# '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.
# '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.
# 'keeptemp' prevents the clean phase from deleting the temp files ($T)
# from a merge.
# '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.
# 'notitles' disables xterm titlebar updates (which contain status info).
# 'sandbox' enable sandbox-ing when running emerge and ebuild
# 'strict' causes portage to react strongly to conditions that
# have the potential to be dangerous -- like missing or
# incorrect Manifest files.
# '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.
# 'usersandbox' enables sandboxing while portage is running under userpriv.
# unpack -- for debugging purposes only.
#FEATURES="sandbox buildpkg ccache distcc userpriv usersandbox notitles noclean noauto cvs keeptemp keepwork"

+ ROCK Linux has a real
sandbox build environment, not this optimization via CFLAGS, and so on
Gentoo wannabe.


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.

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.

-ryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/