[gentoo-dev] [drobbins: Re: portage 1.5]

[gentoo-dev] [drobbins: Re: portage 1.5]

[Daniel Robbins]

Here's a message I sent to Achim privately about the "profiles" issue.  Achim
says he likes this compromise, so we will probably be going with something
similar to this.  This email is a little bit easier to understand than our
last few "deep" Portage conversations, go give it a read.

-Daniel

On Sun, Apr 15, 2001 at 08:15:52PM +0200, Achim Gottinger wrote:

> Hope you did not get confused about our portage.mask conversation.  My last
> alternative was just an attempt to make a compromise that merges your idea of
> the packages file with mine of a package mask. My first wish to use packages
> as a replacement for current-packages whould have messed up yours. And I
> think using the packages file as a profile for the packages that should be
> installed is a good idea and it is not so good to missuse it for version
> specific things.  At my work by BMW I was partly involed in the buerocracy
> processes that where neccesary to update a single package. For such
> environments it is a must to have the full controll over each package. So
> once we sell gentoo we have to face those problems. I think it is more
> efficient to implement such meachnisms now, because ebuild will become more
> complex, likewise the changes.  I thought we have a few developers out there
> who are working for isp's and I'm wondering why no one participates on our
> discussion.

I think we may be talking over a lot of peoples' heads right now simply because
we are the people most familiar with the internal workings of Portage :)

You mentioned that /usr/portage/profiles/[profile]/packages shouldn't be used
for version-specific things.  I agree to a certain extent -- I think we should
avoid putting version-specific things in there if at all possible.

I think I have a simpler compromise.  If what I'm about to suggest is what you
were trying to say all along, I apologize for misunderstanding you :)

Let's do this.  In /usr/portage/profiles, we will have various
*version-specific* profile directories.  For example, instead of having
profiles/default, we'll have profiles/default-1.0_rc4.  When we release a new
version of Portage, we will release a new set of profiles (but keep the older
profiles).  This will allow us to use specific dependencies in
profiles/default-1.0_rc5/packages without forcing 1.0_rc4 systems to upgrade to
1.0_rc5 packages, for example.  This will allow us to use the "packages" file
in a way much more like a "current-packages" file.  However, it will also allow
us to be purposely vague if necessary (to allow for flexibility in our profiles
geared towards advanced users).

Under this arrangement, we'd have a selection of profiles for 1.0_rc5 as follows:

profiles/default-1.0_rc5
profiles/desktop-1.0_rc5
profiles/server-1.0_rc5
profiles/current

The first three are self-explanatory.  The "current" profile will be the
"bleeding edge CVS" system -- in Debian-speak, the "unstable" branch, and in
FreeBSD-speak, the "current" branch.

If someone currently is using the "desktop-1.0_rc5" profile but wants to switch
to the "current" profile, he'd do this:

# cd /etc
# rm make.profile
# ln -s /usr/portage/profiles/current make.profile
# emerge --system

When we release Gentoo Linux 1.0_rc6, we will keep the 1.0_rc5 profiles for
compatibility.  If someone wants to auto-upgrade their system from 1.0_rc5 to 1.0_rc6,
they can do this:

# cd /etc
# rm make.profile (this was pointing to "default-1.0_rc5")
# ln -s /usr/portage/profiles/default-1.0_rc6 make.profile
# emerge --system

We will still have package.mask to mask out "bad" packages globally.

This system should work for everyone.  People who want to be totally up-to-date
can use "current".  People who want a more stable system can use
"default-1.0_rc5" -- and it eliminates the need for cvs branches which would
cause a fork in our Portage namespace (bad for productivity).

What do you think? :)

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