[gentoo-dev] Proposed CVS Cleanup

[gentoo-dev] Proposed CVS Cleanup

[Jerry A!]

I'm thinking that this may be a good time to audit the portage tree and
clean up any cruft.

Specifically:

1. Clean out directories with multiple, older versions of ebuilds.
2. Consolidate portages which are replicated in multiple directories.
3. Consolidate current-packages and current-packages.new into one file.

Why now?  Well, since it looks like most of Gentoo is falling into place
and is growning everyday, now seems like a good time (in my opinion).
Also, it appears as though with the new portage expansions (xpak) being
the building blocks for 1.0_rc5, that this going into this with a
spotless tree may make the work a lot easier.

Anyway, I'd like to know what you all think.  If it does appear like a
good idea, then maybe we should get all the committers together, divide
up the tree and go to town...

        --Jerry

name:  Jerry Alexandratos         ||  Open-Source software isn't a
phone: 703.599.6023               ||  matter of life or death...
email: jerry@thehutt.org          ||  ...It's much more important
                                  ||  than that!

Re: [gentoo-dev] Proposed CVS Cleanup

[drobbins]

On Sun, Feb 18, 2001 at 05:43:22PM -0500, Jerry A! wrote:
> I'm thinking that this may be a good time to audit the portage tree and
> clean up any cruft.
> 
> Specifically:
> 
> 1. Clean out directories with multiple, older versions of ebuilds.
> 2. Consolidate portages which are replicated in multiple directories.
> 3. Consolidate current-packages and current-packages.new into one file.
> 
> Why now?  Well, since it looks like most of Gentoo is falling into place
> and is growning everyday, now seems like a good time (in my opinion).
> Also, it appears as though with the new portage expansions (xpak) being
> the building blocks for 1.0_rc5, that this going into this with a
> spotless tree may make the work a lot easier.
> 
> Anyway, I'd like to know what you all think.  If it does appear like a
> good idea, then maybe we should get all the committers together, divide
> up the tree and go to town...

I think that's a good idea.  We may want to start discussing how to add a new
feature to portage called "system profiles".  This new feature will allow us to
define a certain "type" of Gentoo Linux system, and then list all the packages
that are part of this system.  Users will be able to select from these various
types at system install time.  For example, a user can decide to install a
"minimal server" set of packages, or a "the drobbins ultimate desktop system"
set.  I plan to record user profile information in /usr/portage/profiles, and
it will allow us to replace the current-packages file with a
/usr/portage/profiles/default file.

Now, some questions.

I still haven't decided how this system will work with the USE variable.  Right
now, optional functionality can be enabled or disabled with USE in make.conf,
so that ebuilds know whether to compile-in optional GNOME support into
particular packages, for example.  Will system profiles include their own 
custom USE settings?  It would seem like they'd have to.  They may also have
other special customization files -- any you can think of?

The USE variable also creates some complications for our .tbz2 binaries that
appear on the CD.  What should the default USE settings be?  I'm thinking that
our binaries could cater to a fully-configured system.  If users want to set
up a minimal system, then can install the sys.tbz2 file, set USE appropriately,
and then compile everything else from sources.

Ideas, questions, comments?

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Proposed CVS Cleanup

[Achim Gottinger]

drobbins@gentoo.org wrote:

> On Sun, Feb 18, 2001 at 05:43:22PM -0500, Jerry A! wrote:
> > I'm thinking that this may be a good time to audit the portage tree and
> > clean up any cruft.
> >
> > Specifically:
> >
> > 1. Clean out directories with multiple, older versions of ebuilds.

That's a bit to early I have reworked 1/4 of all our packages and still have alot
to do.
I commit my new packages but I don't add them to current-packages.new.
I introduced alot of new USE triggers but I'm not finished.

>
> > 2. Consolidate portages which are replicated in multiple directories.

Yes there are a few packages that have been moved and the old dirs still exists.
I think it is save to remove them physicaly from the tree. They make life more
complicate
as long as they are there.

>
> > 3. Consolidate current-packages and current-packages.new into one file.

We can simply copy current-package.new to current-packages.
Are there people out there who still use rc3?

>
> >
> > Why now?  Well, since it looks like most of Gentoo is falling into place
> > and is growning everyday, now seems like a good time (in my opinion).
> > Also, it appears as though with the new portage expansions (xpak) being
> > the building blocks for 1.0_rc5, that this going into this with a
> > spotless tree may make the work a lot easier.
> >
> > Anyway, I'd like to know what you all think.  If it does appear like a
> > good idea, then maybe we should get all the committers together, divide
> > up the tree and go to town...
>
> I think that's a good idea.  We may want to start discussing how to add a new
> feature to portage called "system profiles".  This new feature will allow us to
> define a certain "type" of Gentoo Linux system, and then list all the packages
> that are part of this system.  Users will be able to select from these various
> types at system install time.  For example, a user can decide to install a
> "minimal server" set of packages, or a "the drobbins ultimate desktop system"
> set.  I plan to record user profile information in /usr/portage/profiles, and
> it will allow us to replace the current-packages file with a
> /usr/portage/profiles/default file.
>
> Now, some questions.
>
> I still haven't decided how this system will work with the USE variable.  Right
> now, optional functionality can be enabled or disabled with USE in make.conf,
> so that ebuilds know whether to compile-in optional GNOME support into
> particular packages, for example.  Will system profiles include their own
> custom USE settings?  It would seem like they'd have to.  They may also have
> other special customization files -- any you can think of?

Well as long as our dependencies system can not check the USE status of an
installed or required package
people should not change the USE settings.
We should put USE in the profile and maybe output a warning if packages USE
differs from the one in make.conf

>
>
> The USE variable also creates some complications for our .tbz2 binaries that
> appear on the CD.  What should the default USE settings be?  I'm thinking that
> our binaries could cater to a fully-configured system.  If users want to set
> up a minimal system, then can install the sys.tbz2 file, set USE appropriately,
> and then compile everything else from sources.

No he should use the build.tbz2. ( I made a shared version which requires about
100MB instead of 130 for the statically linked one).

Lot of the USE triggers I added are not really interesting for a X system like
svga, ggi or framebuffer support.
Others should be added like using readline, berkleydb, gdbm.

These flags are interesting for embedded systems or for GPL/LGPL only systems.

I will make a list of the ones I use at the moment and post it to that list.

achim~

>
>
> Ideas, questions, comments?
>
> --
> Daniel Robbins                                  <drobbins@gentoo.org>
> President/CEO                                   http://www.gentoo.org
> Gentoo Technologies, Inc.
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev