[gentoo-dev] Cutting down on non-cascaded profiles

[gentoo-dev] Cutting down on non-cascaded profiles

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How long are all those non-cascaded profiles going to stick around? They
make profile changes a mess for anyone who wants to do something crazy
like change default USE flags for everyone. (Who would ever need to do
that?!?!)

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCdKzRXVaO67S1rtsRAuYLAKCxcIKA4V6S9YO6qPYJ/T9xkBAwxACfRejF
JFGq9ZBCAWEkvVc0VBGt3ZM=
=AktL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Stuart Longland]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

Donnie Berkholz wrote:
> How long are all those non-cascaded profiles going to stick around? They
> make profile changes a mess for anyone who wants to do something crazy
> like change default USE flags for everyone. (Who would ever need to do
> that?!?!)

I was just thinking this myself.  Are there any users still using Gentoo
Linux 1.4 or 2004.0?

Certainly the cobalt-mips-1.4 and cobalt-mips-2004.1 profiles can go...
the 2004.2 release for Cobalt machines has been around quite a while
now, and just about everyone (that I know of) has moved up to at least
2004.2, and has probably upgraded from there.
(In any case... new 2005.0 images for Gentoo Linux/MIPS Cobalt are on
the way)

I'd certainly welcome a cleanup here... clean out the dead wood. ;-)

--
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Ned Ludd]

On Sun, 2005-05-01 at 03:17 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> How long are all those non-cascaded profiles going to stick around? 

There exists 48 deprecated profiles in the tree.
I've wondered about this myself about when is a good time to flush them.
(>2 release cycles >1 year?)

How about lets flush the 10 *-2004.[0-1]*/deprecated profiles for
starters?
Or do you wish to propose this might be a good time to flush all 48
profiles that are marked as deprecated?


> They
> make profile changes a mess for anyone who wants to do something crazy
> like change default USE flags for everyone. 


> (Who would ever need to do
> that?!?!)

Only somebody fishing to be abused by the rest of us.

------------------------------------------------------------------
Here is a complete lists of profiles that are candidates 
for 2005 spring cleaning.

./default-x86-2004.2/deprecated
./default-ppc/deprecated
./default-sparc64-1.4/deprecated
./default-linux/ppc/1.0/deprecated
./default-linux/ppc/1.2/deprecated
./default-linux/ppc/1.4/deprecated
./default-linux/ppc/1.0_rc/deprecated
./default-linux/x86/gcc31/deprecated
./default-linux/x86/2004.0/deprecated
./default-linux/x86/2004.2/deprecated
./default-linux/x86/2004.3/deprecated
./default-linux/amd64/gcc34-2004.2/deprecated
./default-linux/alpha/2004.3/deprecated
./default-linux/sparc/sparc32/2004.3/deprecated
./default-linux/sparc/sparc64/2004.2/deprecated
./default-linux/sparc/sparc64/2004.3/deprecated
./default-macos/ppc/10.3/deprecated
./default-macos/ppc/10.4/deprecated
./default-macos/ppc/deprecated
./default-macos/deprecated
./default-sparc-2004.0/deprecated
./hardened-x86-2004.0/deprecated
./default-mips-1.4/deprecated
./default-sparc-1.4/deprecated
./gcc34-x86-2004.2/deprecated
./default-mips-2004.1/deprecated
./gcc33-sparc64-1.4/deprecated
./cobalt-mips-1.4/deprecated
./default-sparc64-2004.0/deprecated
./default-ppc-2004.0/deprecated
./default-ppc-2004.1/deprecated
./default-ppc-2004.2/deprecated
./default-ppc-2004.3/deprecated
./n32-mips-2004.1/deprecated
./default-alpha-1.4/deprecated
./default-macos-10.3/deprecated
./default-macos-10.4/deprecated
./default-ppc64-2004.2/deprecated
./default-ppc64-2004.3/deprecated
./default-amd64-2004.2/deprecated
./uclibc/x86/linux24/deprecated
./uclibc/x86/linux26/deprecated
./default-mips64-1.4/deprecated
./default-alpha-2004.0/deprecated
./cobalt-mips-2004.1/deprecated
./gcc34-amd64-2004.1/deprecated
./default-ppc-1.0/deprecated
./default-ppc-1.4/deprecated


-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Cutting down on non-cascaded profiles

[Duncan]

Stuart Longland posted <4274B10C.5060507@longlandclan.hopto.org>,
excerpted below,  on Sun, 01 May 2005 20:35:56 +1000:

> Donnie Berkholz wrote:
>> How long are all those non-cascaded profiles going to stick around? They
>> make profile changes a mess for anyone who wants to do something crazy
>> like change default USE flags for everyone. (Who would ever need to do
>> that?!?!)
> 
> I was just thinking this myself.  Are there any users still using Gentoo
> Linux 1.4 or 2004.0?

I know the default-amd64-2004.2/deprecated file says it's subject to
removal after 2005.07.01.  I don't remember the date of the last time this
discussion came up (tho I do remember someone posted a nice dependency map
of what profiles depended on what, nice graphic that was!), but I believe
the deprecated files appeared in several of those legacy "flat" profiles
as a result thereof.

Of course, note that the amd64 arch tends to be a bit more forward leaning
than others, including x86, with its larger user base including a decent
segment of conservative "enterprise", or as I'd personally opine,
"legacy", users, so 2004.2 for amd64 probably roughly equates to 2004.0
for x86.  I really can't imagine anyone still on 1.4 that'd be attracted
to Gentoo in the first place, but I'm sure in the large x86 base at least,
there are likely to be some.

Assuming the amd64 profile above was deprecated at about the same time as
the others, July 1st should be a good time to remove them all.  For
those without a specific deadline date in them (I checked the mentioned
cobalt-mips-2004.1, no date there), but that have been deprecated for some
time, sticking the July 1st date notice in them would be a useful thing to
do, for any that might still be using them.  That still gives them ~60
days notice, plus what they had b4 the date was put in.

Of course, should there be dates in any deprecated files already there,
with said dates passed, shoot 'em now and get 'em out of their misery!  <g>

I run amd64, so maybe I'm partial, but I certainly like the set date
thing.  IMO all archs should have a profile deprecation time policy, and
stick dates in their deprecated files as appropriate.  IIRC for amd64,
it's something like 6 or 8 months from the first appearance of the
deprecated file, which is then post-dated appropriately, save for
"development" profiles, which usually come with a short deprecation time
warning (six weeks notice I believe I saw in one) in them from the
beginning.  However, anyone bleeding edge enough to be using "development"
profiles should in practice have moved on to the /next/ profile, usually
the following official release, long before the deprecation notice
appears, anyway.  I know that's always been the case here.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Ned Ludd]

On Sun, 2005-05-01 at 05:31 -0700, Duncan wrote:
> Stuart Longland posted <4274B10C.5060507@longlandclan.hopto.org>,
> excerpted below,  on Sun, 01 May 2005 20:35:56 +1000:
> 
> > Donnie Berkholz wrote:
> >> How long are all those non-cascaded profiles going to stick around? They
> >> make profile changes a mess for anyone who wants to do something crazy
> >> like change default USE flags for everyone. (Who would ever need to do
> >> that?!?!)
> > 

> > I was just thinking this myself.  

> Are there any users still using Gentoo
> > Linux 1.4 or 2004.0?

Yes sorta 1.4.
I still have production servers in place that were based on the
Gentoo-1.2/4 era. The smooth migration path away from 1.4 profiles
correlates to having a proper default-linux/$ARCH/gcc2 profile. 
So far it looks as if only x86 has made this move while every other arch
appears to be letting the <=1.4 profiles rot.

-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Mike Frysinger]

On Sunday 01 May 2005 06:17 am, Donnie Berkholz wrote:
> How long are all those non-cascaded profiles going to stick around?

each arch manager is responsible for their own profiles

all of the x86 ones have been pruned except for default-x86-2004.2 which we 
will keep for a while since there isnt a smooth upgrade path to a newer 
portage without it (older portages crash with cascaded make.defaults)

> They 
> make profile changes a mess for anyone who wants to do something crazy
> like change default USE flags for everyone.

it's simple, dont bother touching the non-cascaded version.  no one said you 
had to :P
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Sun, 2005-05-01 at 13:11 -0400, Mike Frysinger wrote:
> > They 
> > make profile changes a mess for anyone who wants to do something crazy
> > like change default USE flags for everyone.
> 
> it's simple, dont bother touching the non-cascaded version.  no one said you 
> had to :P

Agreed.  I don't touch any of the non-cascaded profiles when doing
updates, especially as they are all deprecated.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

Stuart Longland wrote:
> I'd certainly welcome a cleanup here... clean out the dead wood. ;-)

What would happen to users having *really* old version of Gentoo, say
something from end of 2003? Is there an easy way to upgrade?

TIA,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Stephen P. Becker]

> What would happen to users having *really* old version of Gentoo, say
> something from end of 2003? Is there an easy way to upgrade?
> 
> TIA,
> -jkt
> 

Portage should have been warning such users about using a deprecated
profile for some time now.  So, they should have updated to a new
profile by now. Surely most people have synced portage sometime recently
and done an emerge -uD world.  If somebody is using a portage snapshot
from two years ago, they have more problems than a deprecated profile.

You do realize that for the most part, gentoo versions don't mean very
much, right?  A gentoo install is as current as the portage tree, no
matter what installer was used.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

Stephen P. Becker wrote:
> Portage should have been warning such users about using a deprecated
> profile for some time now.  So, they should have updated to a new
> profile by now. Surely most people have synced portage sometime recently
> and done an emerge -uD world.  If somebody is using a portage snapshot
> from two years ago, they have more problems than a deprecated profile.

What is bad about doing *only* `emerge --sync` and security updates?
This is not my case so it's quite possible that no such users exist (so
the gentoo-dev ml isn't probably the best place to ask if they exist,
btw), but if you do something that will prevent *everyone* who is so
"late with upgrades" from continuing, you'll introduce (IMHO dangerous)
precedence about backward compatibility.

So I'm just asking if those users (even if nobody like that exist) have
an ability to upgrade or at least to carry on with their security
upgrades (which could of course require update of sys-apps/portage, this
is perfectly correct).

Good thing is that `emerge --sync` produces warning about using
deprecated profile, so it will probably catch the attention.

> You do realize that for the most part, gentoo versions don't mean very
> much, right?  A gentoo install is as current as the portage tree, no
> matter what installer was used.

Sure.

TIA,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Stephen P. Becker]

> What is bad about doing *only* `emerge --sync` and security updates?

Nothing, however if they have been doing security only updates, I think
that their install won't be *too* far behind the stable tree.  Besides,
at some point old ebuilds are completely removed from portage anyway,
and therefore there is no support for those versions if somebody tries
to submit a bug.  This is really getting into a whole different
discussion altogether about having a security update only tree, but
there has been talk of this a few times before...search the mailing list
archives.

> This is not my case so it's quite possible that no such users exist (so
> the gentoo-dev ml isn't probably the best place to ask if they exist,
> btw), but if you do something that will prevent *everyone* who is so
> "late with upgrades" from continuing, you'll introduce (IMHO dangerous)
> precedence about backward compatibility.

Removing old profiles will do nothing other than forcing them to set a
new profile.  Changing the profile won't stop people from doing security
only updates.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Stephen P. Becker wrote:
> This is really getting into a whole different
> discussion altogether about having a security update only tree, but
> there has been talk of this a few times before...search the mailing list
> archives.

Yep, of course I know; I wasn't asking for "stable" tree.

> Removing old profiles will do nothing other than forcing them to set a
> new profile.  Changing the profile won't stop people from doing security
> only updates.

Okay, as long as "changing the profile" won't affect people *much* (I
mean if it doesn't break their boxes), it is perfectly correct.

I asked just to make sure that broken /etc/make.profile won't completely
screw up Portage or so :-).

-jkt


-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Stuart Longland]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Jan Kundrát wrote:
> Stephen P. Becker wrote:
> 
> > Removing old profiles will do nothing other than forcing them to set a
> > new profile.  Changing the profile won't stop people from doing security
> > only updates.
> 
> Okay, as long as "changing the profile" won't affect people *much* (I
> mean if it doesn't break their boxes), it is perfectly correct.
> 
> I asked just to make sure that broken /etc/make.profile won't completely
> screw up Portage or so :-).

Actually... things are more likely to break if you leave the system
as-is.  The toolchain and libs will be getting quite old, and while the
updated packages should be backward compatable, they may not be.

Anyway, wouldn't security updates include the core system, rather than
just things like Apache?

-- 
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The only dish I have is what if a new profile doesn't support what they
are attempting to do?  If something is profile masked ( gcc fex ) there
is no way currently for a user to unmask it, even in /etc/portage.

In the end they just might symlink make.profile to /etc/portage/profile
and just make their own, although again it seems rather hackish.

Is there documentation guides for modifying ones own profile?  Certainly
the portage support is mostly there ( if one points make.profile to
/etc/portage/profile it technically is all there ).  I guess as a user
it would be nice to see a migration/setup guide for a profile setup,
perhaps I will write one ;)

Stuart Longland wrote:
> Jan Kundrát wrote:
> 
>>Stephen P. Becker wrote:
>>
>>
>>>Removing old profiles will do nothing other than forcing them to set a
>>>new profile.  Changing the profile won't stop people from doing security
>>>only updates.
>>
>>Okay, as long as "changing the profile" won't affect people *much* (I
>>mean if it doesn't break their boxes), it is perfectly correct.
>>
>>I asked just to make sure that broken /etc/make.profile won't completely
>>screw up Portage or so :-).
> 
> 
> Actually... things are more likely to break if you leave the system
> as-is.  The toolchain and libs will be getting quite old, and while the
> updated packages should be backward compatable, they may not be.
> 
> Anyway, wouldn't security updates include the core system, rather than
> just things like Apache?
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQnbJuGzglR5RwbyYAQJNNQ/+Ofcg2B5tDlACAlYs3tIlSFOs21Q6PzyQ
Nvw5w7qah7lm7goF3qygwGqi7NQwGY04hB3Qp2yIEEhR1gBQkUuh8s9dXrRjobU5
OGhJ4tOyK60L9/RPZw0cy4oLZkVJCYnMYlBa710zzQ9sbJMJPYeR8on8rDhmXsNw
aPTRHhE1EFB2VRELwkbfl3FXp/UzJb0INBab4D61HEtPz4Ie2YTCVN2lGiSt7MYm
ywFR6NInOrnxeB0TSeult+E4WE6CTuaLdIfhcekt+UgPUNrqb70f3Vnr4i08pAb4
1MTT/DeP31CxkWvNT5Jhw4bh4gEBqJm+lMjh2pomKDorJm/P5jGb0rK/a4YLn0A8
VIm3Wkha/wTdhSMUU07JQcAMmjFVruU/usHeWEvCNM1+b7bWRYVwS0iuPu1wVHKc
bHH67oWYYZsN24cX+BOTwiInx51z84OxWxeJf1SDBLu5kDtGj5+wIdE0hxPuBoAR
QnHWIgB6P2iQpAXlpi2KdeO/9ZhxBvRgu54e/3JSHpISVL1zQ2Ok95F+3/DGKXtG
DoDOVSMMLTtpXZR6SlTIAjKr5dULAnNBPd2egDHDNxLPWZNJZP+cL+Hxl80dgmnI
O0taYtrsFaXQ/25HDyjEn6Tn3DtFcrmGWBkPA6salKRNxfGlTQasjkpSVPZGMThc
2qMTbZpY2jQ=
=Briz
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Mike Frysinger]

On Monday 02 May 2005 08:45 pm, Alec Warner wrote:
> The only dish I have is what if a new profile doesn't support what they
> are attempting to do?  If something is profile masked ( gcc fex ) there
> is no way currently for a user to unmask it, even in /etc/portage.

yes there is, you just didnt read enough in `man portage`
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Monday 02 May 2005 08:45 pm, Alec Warner wrote:
> 
>>The only dish I have is what if a new profile doesn't support what they
>>are attempting to do?  If something is profile masked ( gcc fex ) there
>>is no way currently for a user to unmask it, even in /etc/portage.
> 
> 
> yes there is, you just didnt read enough in `man portage`
> -mike

apparently I didn't ;)  *goes off to unmask things*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQnbUX2zglR5RwbyYAQIm9Q/9Hm+1y5sQv+sDturHheKQCANN4l/tXARP
Kr+5H8WMkD895VeiRQPZdae1fjyul6wmY0hjYYP+pXnKLe48Cn5CygwRDkqajgzN
j3n012hXeJXF3c8cXh1XvMeaXt5llVT5LKfOaLp0hoXAPb7JzXdfacUFbRdHIGaS
000vJFyssP6e9+ZyNQOcDhJr0YS6+pB0Mk/+WZEBg4mDFckQ+kgNrLTXgp2r1QMz
jH/sharmAPDUJQfU+BbD34f0X1XgMQRCjIsSdapxOnTRaaOmrUQWyU9s0jgS4w//
yktqNdUNn4vLsz3ROuXWZU7Ju0nkhbMbHb4PwA/vH+tIryt3AeJNTUTMbhTbQuhP
KoE1gMuPhk/rXZQ8wM5fseqC+Z50jZZ54o7OtQoGk3Ol09aiBpCfB7EP9IJXGGFl
+2PqoIAf3bNDkej6nyCEK21weDB7uiiwVBtx/EWV4oLgb2tdDjB1o0A/nsh5Oe0E
/OCBZI7JtmO3CY7WhZ/7AyHs/2TFVXReIjywHHcpwx9wQpkoqBXuIWkHjfFuKKab
p6nXrUpDMojvyRk5Cw09+/XZmrE9wFqley/HPnLnciygtyeEXrq07neZaZY9ZtQX
ZUuumrwfpsk8kRXJETDy5KuK8os83MKoohGSRKONTPxs1fVJNT2h/FD47RDNjXDq
M5yepQ3SsPg=
=Iitj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Stuart Longland wrote:
> Anyway, wouldn't security updates include the core system, rather than
> just things like Apache?

Security updates are updates which are fixing *security* problems.
Upgrading glibc is not a security update, IMHO :-).

-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Stuart Longland]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

Jan Kundrát wrote:
> Stuart Longland wrote:
> 
>>Anyway, wouldn't security updates include the core system, rather than
>>just things like Apache?
> 
> 
> Security updates are updates which are fixing *security* problems.
> Upgrading glibc is not a security update, IMHO :-).
> 

Yep... 100% agree... but {g,µC,diet,bsd,whatever}libc is not immune to
security issues. :-)  It's a piece of code which can contain exploitable
defects like everything else.  In fact, this makes things worse, as it's
a piece of code that's linked into just about every application on the
system.

Having said that... sometimes there's a lot to be said for the "if it
ain't broke -- don't fix it" attitude. ;-)  Not to mention, security
through obsolecence -- which you see in action whenever you see a
website running on Linux 2.x (where x < 4) or Windows NT 4.0.

If it's seriously a problem... make a copy of the profile whilst it
still exists, and delete the 'deprecated' file you see in there -- that
will stop Portage from complaining.  Mind you... no guarantees that this
won't break your system either.  (whether it should break now, or 6
months down the track -- is irrelevant)

-- 
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
> How long are all those non-cascaded profiles going to stick around? They
> make profile changes a mess for anyone who wants to do something crazy
> like change default USE flags for everyone. (Who would ever need to do
> that?!?!)

The new profiles.desc format should solve this problem (what's valid and not)
whenever it's added.  What's the ETA on this anyways?  Doesn't the latest
repoman support it?

- --
Ah, sweet pity: where would my love life have been without it?

		-- Homer Simpson
		   I Love Lisa

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCdzwEC3poscuANHARAnHCAJwILYnzhXPAigDgWn86qXeKohRDuQCcDSOE
DLag0JxDkRvfsuCqFiI0qXU=
=5z2v
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Mike Frysinger]

On Tuesday 03 May 2005 03:05 am, Stuart Longland wrote:
> Jan Kundrát wrote:
> > Stuart Longland wrote:
> >>Anyway, wouldn't security updates include the core system, rather than
> >>just things like Apache?
> >
> > Security updates are updates which are fixing *security* problems.
> > Upgrading glibc is not a security update, IMHO :-).
>
> Yep... 100% agree... but {g,µC,diet,bsd,whatever}libc is not immune to
> security issues. :-)

and to prove the point we have a few GLSA's for glibc
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Tuesday 03 May 2005 17:53, Aaron Walker wrote:
> Donnie Berkholz wrote:
> > How long are all those non-cascaded profiles going to stick around? They
> > make profile changes a mess for anyone who wants to do something crazy
> > like change default USE flags for everyone. (Who would ever need to do
> > that?!?!)
>
> The new profiles.desc format should solve this problem (what's valid and
> not) whenever it's added.  What's the ETA on this anyways?  Doesn't the
> latest repoman support it?

There is no change in format. There was only the question of whether multiple 
profiles per architecture is supported. From 2.0.51.20 onward, it is.

Regards,
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Cutting down on non-cascaded profiles

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Tue, 2005-05-03 at 04:53 -0400, Aaron Walker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Donnie Berkholz wrote:
> > How long are all those non-cascaded profiles going to stick around? They
> > make profile changes a mess for anyone who wants to do something crazy
> > like change default USE flags for everyone. (Who would ever need to do
> > that?!?!)
> 
> The new profiles.desc format should solve this problem (what's valid and not)
> whenever it's added.  What's the ETA on this anyways?  Doesn't the latest
> repoman support it?

Yes, the last 2 repoman versions have supported the new format.  I plan
on adding all of the profiles that I know are valid, and working with
other teams to ensure their valid profiles are listed, also.

Right now, I'm just hoping to see portage versions >= 2.0.51.20 be more
prevalent in #gentoo-commits before taking the plunge and changing
this... or perhaps repoman complaining loudly every time they try to use
it will give people a bit of motivation to upgrade?  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Cutting down on non-cascaded profiles

[Duncan]

Stephen P. Becker posted <42765654.3010404@gentoo.org>, excerpted below, 
on Mon, 02 May 2005 12:33:24 -0400:

> Removing old profiles will do nothing other than forcing them to set a new
> profile.  Changing the profile won't stop people from doing security only
> updates.

Except that isn't quite correct, for that
deprecated-profile-security-update-only person we're talking about.

Such a person isn't likely to have a version of portage that can handle
cascading profiles, which /is/ after all what the thread is about, and
gcc and other parts of the toolchain are likely to be equally outdated
(gcc-2.95, python 2.2, maybe earlier, etc). Remove their flat profile, and
they may have an entirely broken portage, which they can't fix because
they can no longer parse the tree, and may not be able to compile certain
dependencies to get it working again even if they could.

I haven't taken a look at the emergency procedures for a broken portage,
recently, altho IIRC it now simply points to a place where a binary
package can be downloaded.  Are those procedures and binary package
updated enough to cope with cascading profiles, while still being backward
compatible with python 2.2 and gcc 2.95?

Consider a user off the net, at least as far as the bandwidth necessary to
do upgrades, for a year and a half.  Maybe they were a missionary to some
remote location for the period, or "unavoidably detained" for political or
other reasons.  They finally get back to "Internet civilisation", and find
their Gentoo so outdated they can't even update it!

Of course, if they're /that/ far out of date, perhaps a new install,
stage-three and packages CD, is the most efficient way to get up and
running again.  That'd be my approach, if I found myself syncing after a
year and a half out of circulation, and further assuming my machine
(and personal know-how) was even more outdated, such that a stage-1
install didn't sound palatable.

Is there a convenient profile archive somewhere?  If not, perhaps one
should be created, and at deletion from the tree, the profile dir in
question is replaced with a file (or the empty dir with only that
file) pointing to the archive.  This archive could then keep the last
workable profile snapshot around for another six months or so, or perhaps
even forever, given the cost of storage now days.  The pointer to it in
the tree could then be removed 30 days or 6 months after the profile
itself was removed, /forcing/ action on any laggards.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

On Tue, 2005-05-03 at 08:21 -0700, Duncan wrote:
> Is there a convenient profile archive somewhere?  If not, perhaps one
> should be created, and at deletion from the tree, the profile dir in
> question is replaced with a file (or the empty dir with only that
> file) pointing to the archive.  This archive could then keep the last
> workable profile snapshot around for another six months or so, or perhaps
> even forever, given the cost of storage now days.  The pointer to it in
> the tree could then be removed 30 days or 6 months after the profile
> itself was removed, /forcing/ action on any laggards.

I think an easier solution would be a portage rescue set of profiles.
These would be minimal profiles not designed for actual use, but only
for performing a portage update for those people that lag too far
behind.  The idea would be a very tiny profile, per arch, that is not
cascaded.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Cutting down on non-cascaded profiles

[Duncan]

Chris Gianelloni posted <1115136614.889.281.camel@cgianelloni.nuvox.net>,
excerpted below,  on Tue, 03 May 2005 12:10:14 -0400:

> I think an easier solution would be a portage rescue set of profiles.
> These would be minimal profiles not designed for actual use, but only for
> performing a portage update for those people that lag too far behind.  The
> idea would be a very tiny profile, per arch, that is not cascaded.

I like!  In some cases, they may be combine-able, as well multiple archs
to a profile, if they are sufficiently minimal.  They could remain for
some time to point people to if/as necessary.

My idea for an archive was that this should be pretty low traffic, and
would get it off the rsync mirrors and clean out the profile tree, making
things less confusing.  However, put them in a single "emergency-profile"
subtree, and make them tiny enough, and it would do almost as well, while
at the same time still being conveniently located in the portage tree.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Mike Frysinger]

On Tuesday 03 May 2005 12:10 pm, Chris Gianelloni wrote:
> I think an easier solution would be a portage rescue set of profiles.

afaik the only thing it'd need is a 'make.defaults' and a custom 
'packages' (where we'd force a newer version of portage of course)

i dont think we even need a set, we could just do it with one ... after all, 
we can stick bash code into make.defaults and have it do something ugly like 
run `uname` or parse make.defaults to figure out the correct ARCH
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, 2005-05-03 at 14:49 -0400, Mike Frysinger wrote:
> On Tuesday 03 May 2005 12:10 pm, Chris Gianelloni wrote:
> > I think an easier solution would be a portage rescue set of profiles.
> 
> afaik the only thing it'd need is a 'make.defaults' and a custom 
> 'packages' (where we'd force a newer version of portage of course)
> 
> i dont think we even need a set, we could just do it with one ... after all, 
> we can stick bash code into make.defaults and have it do something ugly like 
> run `uname` or parse make.defaults to figure out the correct ARCH

If you're feeling up to the bash-fu, I was trying to propose something
simple, but this would probably be the best solution.

So does anyone have any objections yet? ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Tue, 3 May 2005 14:49:54 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Tuesday 03 May 2005 12:10 pm, Chris Gianelloni wrote:
> > I think an easier solution would be a portage rescue set of
> > profiles.
> 
> afaik the only thing it'd need is a 'make.defaults' and a custom 
> 'packages' (where we'd force a newer version of portage of course)
> 
> i dont think we even need a set, we could just do it with one ...
> after all,  we can stick bash code into make.defaults and have it do
> something ugly like  run `uname` or parse make.defaults to figure out
> the correct ARCH 
> -mike

Please no bash code in make.defaults other than variable assignments,
portage doesn't source it but uses a simle python parser.
Oh, and profile.bashrc isn't available either in those old portage
versions.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Tuesday 03 May 2005 09:10, Chris Gianelloni wrote:
> I think an easier solution would be a portage rescue set of profiles.
> These would be minimal profiles not designed for actual use, but only
> for performing a portage update for those people that lag too far
> behind.  The idea would be a very tiny profile, per arch, that is not
> cascaded.

Perhaps another solution would be to create a system with archives of the 
profiles and packages necessary to do an upgrade from an old portage and 
profile to a new portage and profile, seeing as portage has circular 
effective dependencies on at least the tree and python, perhaps other stuff 
as well. This could be some sort of script which downloads the archive, then 
upgrades, one major shift at a time.

Once said system is in place, notices could be put in the deprecated files 
(and of course the homepage) to that effect, and the old profiles removed 
from the main tree after a while.

Just a thought.

--electronerd

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Tuesday 03 May 2005 23:05, Chris Gianelloni wrote:
> On Tue, 2005-05-03 at 14:49 -0400, Mike Frysinger wrote:
> > On Tuesday 03 May 2005 12:10 pm, Chris Gianelloni wrote:
> > > I think an easier solution would be a portage rescue set of profiles.
> >
> > afaik the only thing it'd need is a 'make.defaults' and a custom
> > 'packages' (where we'd force a newer version of portage of course)
> >
> > i dont think we even need a set, we could just do it with one ... after
> > all, we can stick bash code into make.defaults and have it do something
> > ugly like run `uname` or parse make.defaults to figure out the correct
> > ARCH
>
> If you're feeling up to the bash-fu, I was trying to propose something
> simple, but this would probably be the best solution.
>
> So does anyone have any objections yet? ;]

What about adding a "panic" mode to portage which, when confronted with a 
missing profile, (and after confirmation) continues to upgrade portage to the 
latest version it can find with some default settings that should allways 
work.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Mike Frysinger]

On Monday 09 May 2005 04:12 pm, Paul de Vrieze wrote:
> What about adding a "panic" mode to portage which, when confronted with a
> missing profile, (and after confirmation) continues to upgrade portage to
> the latest version it can find with some default settings that should
> allways work.

looking ahead that's a good idea but for older portages that doesnt help at 
all ... the profiles we're talking about here will break when given a 
cascaded profile
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Brian Harring]

On Mon, May 09, 2005 at 10:12:03PM +0200, Paul de Vrieze wrote:
> What about adding a "panic" mode to portage which, when confronted with a 
> missing profile, (and after confirmation) continues to upgrade portage to the 
> latest version it can find with some default settings that should allways 
> work.
Can't see any tenuable way to pull it off; without the profile, 
keywording can be something of a crapshoot (consider p.mask'ed portage 
versions, which do, and will continue to, occur).

Depends on your definition of default though I spose; I'd expect it 
would require a portage modification though :)
~brian
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Monday 09 May 2005 22:27, Mike Frysinger wrote:
> On Monday 09 May 2005 04:12 pm, Paul de Vrieze wrote:
> > What about adding a "panic" mode to portage which, when confronted
> > with a missing profile, (and after confirmation) continues to upgrade
> > portage to the latest version it can find with some default settings
> > that should allways work.
>
> looking ahead that's a good idea but for older portages that doesnt
> help at all ... the profiles we're talking about here will break when
> given a cascaded profile

I know. But I'm certain that todays profiles will need to be removed in 
the future. And quite possibly there will be things that break very old 
portage versions.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

maillog: 10/05/2005-11:15:45(+0200): Paul de Vrieze types
> On Monday 09 May 2005 22:27, Mike Frysinger wrote:
> > On Monday 09 May 2005 04:12 pm, Paul de Vrieze wrote:
> > > What about adding a "panic" mode to portage which, when confronted
> > > with a missing profile, (and after confirmation) continues to upgrade
> > > portage to the latest version it can find with some default settings
> > > that should allways work.
> >
> > looking ahead that's a good idea but for older portages that doesnt
> > help at all ... the profiles we're talking about here will break when
> > given a cascaded profile
> 
> I know. But I'm certain that todays profiles will need to be removed in 
> the future. And quite possibly there will be things that break very old 
> portage versions.

Why do you need to remove them? Keep them there with the obsolete
warning and hard-code the newer portage to exclude those profiles when
syncing as to not clutter user's trees.  Maybe even add a
$PORTDIR/profiles/rsync_excludes file that will have a list of stuff to
be excluded. Portage can then use that file as another "--exclude-from
$PORTDIR/profiles/rsync_excludes".

-- 
(*   Georgi Georgiev   (* Of course you have a purpose -- to find a    (*
*)    chutz@gg3.net    *) purpose.                                     *)
(*  +81(90)2877-8845   (*                                              (*

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]