Re: [gentoo-dev] RFC: multiple inheritance support for profiles

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Ciaran McCreesh wrote:
> On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico <zmedico@gentoo.org>
> wrote:
> | Currently, portage only allows single inheritance in profiles, but
> | it's easy to enable multiple inheritance.  In order to do this, we
> | only need to unconstrain the number of parents allowed in the parent
> | file (only 1 is currently allowed).  When a parent file contains
> | multiple parents, parents listed later if the file will have the
> | ability to override those listed earlier in the file.

I still like Mixin's[1] with node deps ;)

[1] 
http://dev.gentoo.org/~antarus/projects/portage/mixin-profiles/mixin-profiles.txt
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] RFC: multiple inheritance support for profiles

[Zac Medico]

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

Hi everyone,

Currently, portage only allows single inheritance in profiles, but it's easy to enable multiple inheritance.  In order to do this, we only need to unconstrain the number of parents allowed in the parent file (only 1 is currently allowed).  When a parent file contains multiple parents, parents listed later if the file will have the ability to override those listed earlier in the file.

Multiple inheritance seems like it would add useful flexibility to the profile structure.  Should we remove the single inheritance constraint and allow multiple inheritance?

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE3jkN/ejvha5XGaMRApIfAJ0cYXsowPFPrfLIZwwLfdsSV+W+LwCcCmkN
1FUrNNnNcb6PyIxLGGSSZLg=
=rzHQ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Ciaran McCreesh]

On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico <zmedico@gentoo.org>
wrote:
| Currently, portage only allows single inheritance in profiles, but
| it's easy to enable multiple inheritance.  In order to do this, we
| only need to unconstrain the number of parents allowed in the parent
| file (only 1 is currently allowed).  When a parent file contains
| multiple parents, parents listed later if the file will have the
| ability to override those listed earlier in the file.

One per line?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Ciaran McCreesh wrote:
> On Sat, 12 Aug 2006 16:11:25 -0400 Alec Warner <antarus@gentoo.org>
> wrote:
> | Ciaran McCreesh wrote:
> | > On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico <zmedico@gentoo.org>
> | > wrote:
> | > | Currently, portage only allows single inheritance in profiles, but
> | > | it's easy to enable multiple inheritance.  In order to do this, we
> | > | only need to unconstrain the number of parents allowed in the
> | > | parent file (only 1 is currently allowed).  When a parent file
> | > | contains multiple parents, parents listed later if the file will
> | > | have the ability to override those listed earlier in the file.
> | 
> | I still like Mixin's[1] with node deps ;)
> 
> You can get the best of both worlds using straight MI, if the profile
> tree is structured properly. Use the existing hierarchy for the 'main'
> profile and mixins (nodes with no parent) as extras. The only problem
> with this is Portage's current reliance upon a single symlink to
> specify the profile... With Paludis one could do:
> 
> profiles = default-linux/x86/2006.0 extra/x86/pentium4 extra/misc/cookie
> 
> but with /etc/make.profile that's not an option...
> 

Hmmm This sounds a lot more like what Kumba wanted than my original 
thoughts ;)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Zac Medico]

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

Ciaran McCreesh wrote:
> On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico <zmedico@gentoo.org>
> wrote:
> | Currently, portage only allows single inheritance in profiles, but
> | it's easy to enable multiple inheritance.  In order to do this, we
> | only need to unconstrain the number of parents allowed in the parent
> | file (only 1 is currently allowed).  When a parent file contains
> | multiple parents, parents listed later if the file will have the
> | ability to override those listed earlier in the file.
> 
> One per line?
> 

Yes, you read my mind.  ;)

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE3kBj/ejvha5XGaMRAvlrAKCO0xCvYWRxqBi5hWdv27NPkfmY7gCg6oZr
8ofW1QCbSJ8WtlEYh7d5MIA=
=ycKr
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Ciaran McCreesh]

On Sat, 12 Aug 2006 16:11:25 -0400 Alec Warner <antarus@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico <zmedico@gentoo.org>
| > wrote:
| > | Currently, portage only allows single inheritance in profiles, but
| > | it's easy to enable multiple inheritance.  In order to do this, we
| > | only need to unconstrain the number of parents allowed in the
| > | parent file (only 1 is currently allowed).  When a parent file
| > | contains multiple parents, parents listed later if the file will
| > | have the ability to override those listed earlier in the file.
| 
| I still like Mixin's[1] with node deps ;)

You can get the best of both worlds using straight MI, if the profile
tree is structured properly. Use the existing hierarchy for the 'main'
profile and mixins (nodes with no parent) as extras. The only problem
with this is Portage's current reliance upon a single symlink to
specify the profile... With Paludis one could do:

profiles = default-linux/x86/2006.0 extra/x86/pentium4 extra/misc/cookie

but with /etc/make.profile that's not an option...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Andrew Gaffney]

Alec Warner wrote:
> Ciaran McCreesh wrote:
>> You can get the best of both worlds using straight MI, if the profile
>> tree is structured properly. Use the existing hierarchy for the 'main'
>> profile and mixins (nodes with no parent) as extras. The only problem
>> with this is Portage's current reliance upon a single symlink to
>> specify the profile... With Paludis one could do:
>>
>> profiles = default-linux/x86/2006.0 extra/x86/pentium4 extra/misc/cookie
>>
>> but with /etc/make.profile that's not an option...
> 
> Hmmm This sounds a lot more like what Kumba wanted than my original 
> thoughts ;)

This is pretty much exactly what Kumba was talking about. I didn't like the idea 
simply because it allowed the user to shoot themselves in the foot way too 
easily. It will also cause QA problems, since the profiles wouldn't be strictly 
controlled by the arch teams and releng anymore.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Ciaran McCreesh]

On Sat, 12 Aug 2006 16:54:41 -0500 Andrew Gaffney <agaffney@gentoo.org>
wrote:
| It will also cause QA problems, since the profiles wouldn't be
| strictly controlled by the arch teams and releng anymore.

Uh, that's easily solved. Demand that anyone changing non-arch profile
things gets prior approval from -dev, and string up anyone who doesn't.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Ciaran McCreesh wrote:
> On Sat, 12 Aug 2006 16:54:41 -0500 Andrew Gaffney <agaffney@gentoo.org>
> wrote:
> | It will also cause QA problems, since the profiles wouldn't be
> | strictly controlled by the arch teams and releng anymore.
> 
> Uh, that's easily solved. Demand that anyone changing non-arch profile
> things gets prior approval from -dev, and string up anyone who doesn't.
> 

I think moreso he meants that users could mix in stupid stuff together 
and then blame Gentoo.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Curtis Napier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Alec Warner wrote:
> Ciaran McCreesh wrote:
>> On Sat, 12 Aug 2006 16:54:41 -0500 Andrew Gaffney <agaffney@gentoo.org>
>> wrote:
>> | It will also cause QA problems, since the profiles wouldn't be
>> | strictly controlled by the arch teams and releng anymore.
>>
>> Uh, that's easily solved. Demand that anyone changing non-arch profile
>> things gets prior approval from -dev, and string up anyone who doesn't.
>>
> 
> I think moreso he meants that users could mix in stupid stuff together
> and then blame Gentoo.

But users can already do all sorts of stupid things and blame gentoo. In
fact, they already do. Just look at bugzilla or ask jakub.

As long as we continue to enforce the posting of emerge --info on bugs
this shouldn't be a problem. Any bug submitted with a user-screwed-it-up
profile can just be closed with a WONTFIX and a short explanation of
what they did wrong. Just like we do it now for a million other things.

Let's not hold anyones hand, let them make their mistakes and learn from
them. That philosophy is at the heart of Gentoo and the main reason I
use it.

- --curtis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBRN57U0b8Q0uRCeTQAQEjJQf/RfD9Jsf1ODBdsoEXDak8W6OeJesiNLZq
mDqV7ZWXhV1OtbPz1zYGxVeiAfpcNVNuPlvEmPuP5T1eQ7z5bPEr18w22wpzm0tn
itXvo7iqUQBu6QydtG0ly8ZKJVQAeXp5kqb48oTxLSg+Y13/hJ2BSNZCrLgNG0RB
mJjFT+Wb4QFK8UzREXuluTl9SxwBPpIGJc67aZVa0T1ZhF/tw1ojwSNIRO0CCm19
3YK2plPzTyLge8KjFvNEN6ql7gTbHZ3fvAJ+ANvX2MWiMLT8egrrLpCIq+SsYyZi
Q2I6GOKA7V1SwcrrPaCSlk92ASuUqznYK/kF3DZQXsyupXTVBv6R2A==
=ONew
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Brian Harring]

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

On Sat, Aug 12, 2006 at 01:24:49PM -0700, Zac Medico wrote:
> Hi everyone,
> 
> Currently, portage only allows single inheritance in profiles, but 
> it's easy to enable multiple inheritance.  In order to do this, we 
> only need to unconstrain the number of parents allowed in the parent 
> file (only 1 is currently allowed).  When a parent file contains 
> multiple parents, parents listed later if the file will have the 
> ability to override those listed earlier in the file.
> 
> Multiple inheritance seems like it would add useful flexibility to 
> the profile structure.

Unfortunately, portages long time handling of N parents sucks.

> Should we remove the single inheritance 
> constraint and allow multiple inheritance?

Said single inheritance protection was added 06/05/06 (rev 3544), 
stabled for x86 roughly 06/22/06.

Hasn't even yet made it to a release media- meaning folk installing 
from the most current release media still can get bit in the ass by 
switching to an N parent from the get go.

So... basic question is how this is actually going to protect users 
from stumbling into it?

There *are* a lot of folk who let things linger, and 2.1 (not 2.1.1 
holding said rev) held the major reason to upgrade, 2.1.1 being just 
bug fixups.  Point I'm trying to get across here is that there are 
still going to be a fair chunk of folk lacking the protection; combine 
that with the long standing capability to nag users to upgrade their 
profiles, and you've got the core reason this support isn't already in 
portage- if a user upgrades without the protection, they wind up with 
only half of the profile (best case).

Move forward with it, but even if support exists, it still must sit 
for long enough to avoid screwing over anyone but the biggest 
slackers- this would include ensuring that the appropriate portage dep 
is in both branches; do that, and you've minimized it as much as 
possible.

So... what's the plan in that regard?
~harring

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

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Kumba]

Andrew Gaffney wrote:
> 
> This is pretty much exactly what Kumba was talking about. I didn't like 
> the idea simply because it allowed the user to shoot themselves in the 
> foot way too easily. It will also cause QA problems, since the profiles 
> wouldn't be strictly controlled by the arch teams and releng anymore.

Just so it's clear, this is mostly what I was thinking up a few years ago when 
what is the current profiling system was being figured out (back when we had 
separate profile folders for everything -- ~2004.x timeframe).  ferringb quickly 
pointed a few flaws with letting the user have complete control over the 
ordering, and so I revised my idea to have the base components fixed in a 
specific order like so:

base:os:arch:userland

So a mips-unknown-linux-uclibc user would set a profile much like:
	PORTAGE_PROFILE="base:linux:mips:uclibc:"

FreeBSD/x86 user might use:
	PORTAGE_PROFILE="base:freebsd:x86:bsdlibc"

And so on.  This would fix the core components' order in a specific way.  Once 
the four base elements are set, the user is free to add on "extra" nodes that 
add or enhance the functionality of the core profile.  Like hardened or 
embedded, for example. (base:linux:x86:glibc:hardened)

Antarus added another idea on earlier today that'd make it more robust by making 
the nodes have depends, and via that, portage can yell at the user if they mix 
something improperly, say they have a glibc userland, and they try to add the 
embedded profile.  Since the idea of embedded with glibc is a bit silly 
(Although not impossible), portage can do one of two things: yell at the user 
that they need to switch to a uclibc userland, or ignore using the embedded 
node, because embedded depends on uclibc.

My thinking in all of this is to make the profile/ folder layout a little saner, 
but this idea has really only existed as just an idea.  It's not had a really 
good looking at by some of the portage experts aside from ferringb or antarus -- 
and they quickly highlighted several shortcomings.  In a way, though, I kind of 
envision profiles/ looking somewhat like this (Sample):

profiles/
   |
   |--base/
   |
   |--abi/
   |   |
   |   |--n32/
   |   |--o32/
   |   |--v9/
   |
   |--arch/
   |   |
   |   |--mips/
   |   |--sparc/
   |   |--x86/
   |
   |--endian/
   |   |
   |   |--be/
   |   |--le/
   |
   |--os/
   |   |
   |   |--linux/
   |   |--freebsd/
   |
   |--threads/
   |   |
   |   |--linuxthreads/
   |   |--nptl/
   |
   |--userland/
   |   |
   |   |--bsdlibc/
   |   |--glibc/
   |   |--uclibc/
   |
   |--xtra/
   |   |
   |   |--embedded/
   |   |--hardened/

Most arches I can imagine won't make use of half the nodes listed here, as some 
are restricted in what they can do.  Most of it is based on my experiences in 
trying to devise future expandibility for the mips arch, as there are about a 
zillion different ways to string things together for us, like so:

base:linux:mips:glibc:n32:nptl:be (mips big-endian, glibc, NPTL, N32 ABI)
base:linux:mips:uclibc:o32:linuxthreads:le:embedded (mips little-endian, uclibc, 
linuxthreads, embedded, O32 ABI)
base:linux:mips:uclibc:n32:nptl:be (mips big-endian, uclibc, NPTL, N32 ABI)

And so on.  Of course, not all of them are used, but it's a bad habit of mine to 
think that far ahead into the future.  Most of this is made up as I go along. 
None of it has ever really been put down in writing, except one version that 
Antarus examined a few months ago in what he called "Mix n' Match", or "Mixin" 
form, and as more people ponder this idea and either shoot holes through it or 
add on more ways to better implement it, I guess will determine whether or not 
it'll ever be feasible.

I think if properly implemented right, it might allow for some degree of control 
by the user while letting the devs keep users from completely shooting their own 
legs off at the knee joint, and make the profile system more robust and saner to 
manage.


Thoughts?


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Zac Medico]

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

Brian Harring wrote:
> Said single inheritance protection was added 06/05/06 (rev 3544), 
> stabled for x86 roughly 06/22/06.
> 
> Hasn't even yet made it to a release media- meaning folk installing 
> from the most current release media still can get bit in the ass by 
> switching to an N parent from the get go.

I'm not sure what the probability of people hurting themselves like this is.  Perhaps it's a negligible corner case and a note in the upgrade guide will be enough to keep the vast majority of users on the right track.  I'd hope that a user would be wise enough to read some docs prior to switching to a new profile with a potentially outdated version of portage.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE3r/M/ejvha5XGaMRAk+uAKCsWqMuufcxS+Gha8B/ktMBhzfxaACgp7YI
TKateq0dtsgv3yyuccfRh/4=
=qeiO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Brian Harring]

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

On Sat, Aug 12, 2006 at 10:59:48PM -0700, Zac Medico wrote:
> Brian Harring wrote:
> > Said single inheritance protection was added 06/05/06 (rev 3544), 
> > stabled for x86 roughly 06/22/06.
> > 
> > Hasn't even yet made it to a release media- meaning folk installing 
> > from the most current release media still can get bit in the ass by 
> > switching to an N parent from the get go.
> 
> I'm not sure what the probability of people hurting themselves like 
> this is.

Probably is related to how quickly N profile is uptaken, how 
widespread, and (assuming it's used to do base profile, and shallow 
decoration, gnome specific fex) ordering of the base profile vs the 
shallow profile.


> Perhaps it's a negligible corner case and a note in the 
> upgrade guide will be enough to keep the vast majority of users on 
> the right track.

Upgrade guide being what, profile deprecated notices?

> I'd hope that a user would be wise enough to read 
> some docs prior to switching to a new profile with a potentially 
> outdated version of portage.

And users hope that the developers don't leave land mines around :)

This *can* be one helluva land mine; I already listed ways to at least 
manually address it from a dev standpoint (forced portage deps in each 
branch).

Like I said in the last email (and was snipped from the response), 
this needs to level additional protective measures to avoid users 
getting bit- it should be seemless (well aware that's not always 
easy).
~harring

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

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Zac Medico wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brian Harring wrote:
> 
>>Said single inheritance protection was added 06/05/06 (rev 3544), 
>>stabled for x86 roughly 06/22/06.
>>
>>Hasn't even yet made it to a release media- meaning folk installing 
>>from the most current release media still can get bit in the ass by 
>>switching to an N parent from the get go.
> 
> 
> I'm not sure what the probability of people hurting themselves like this is.  Perhaps it's a negligible corner case and a note in the upgrade guide will be enough to keep the vast majority of users on the right track.  I'd hope that a user would be wise enough to read some docs prior to switching to a new profile with a potentially outdated version of portage.
> 

Damn your mail client ;)

The past[1] has shown that users don't read docs.

[1] http://bugs.gentoo.org/show_bug.cgi?id=63400

> Zac
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
> iD8DBQFE3r/M/ejvha5XGaMRAk+uAKCsWqMuufcxS+Gha8B/ktMBhzfxaACgp7YI
> TKateq0dtsgv3yyuccfRh/4=
> =qeiO
> -----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Marius Mauch]

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

On Sun, 13 Aug 2006 13:01:41 -0400
Alec Warner <antarus@gentoo.org> wrote:

> Zac Medico wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Brian Harring wrote:
> > 
> >>Said single inheritance protection was added 06/05/06 (rev 3544), 
> >>stabled for x86 roughly 06/22/06.
> >>
> >>Hasn't even yet made it to a release media- meaning folk installing 
> >>from the most current release media still can get bit in the ass by 
> >>switching to an N parent from the get go.
> > 
> > 
> > I'm not sure what the probability of people hurting themselves like
> > this is.  Perhaps it's a negligible corner case and a note in the
> > upgrade guide will be enough to keep the vast majority of users on
> > the right track.  I'd hope that a user would be wise enough to read
> > some docs prior to switching to a new profile with a potentially
> > outdated version of portage.
> > 
> 
> Damn your mail client ;)
> 
> The past[1] has shown that users don't read docs.
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=63400

And don't forget the "virtuals" bug. Remember the discussion about repo
versioning? These are all use cases for it, so if a new profile format
is getting introduced we should really implement that versioning
support.

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: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Zac Medico wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alec Warner wrote:
> 
>>Zac Medico wrote:
>>I'm not sure what the probability of people hurting themselves like
>>this is.  Perhaps it's a negligible corner case and a note in the
>>upgrade guide will be enough to keep the vast majority of users on the
>>right track.  I'd hope that a user would be wise enough to read some
>>docs prior to switching to a new profile with a potentially outdated
>>version of portage.
>>
>>
>>
>>>Damn your mail client ;)
>>
>>>The past[1] has shown that users don't read docs.
>>
>>>[1] http://bugs.gentoo.org/show_bug.cgi?id=63400
> 
> 
> Perhaps users that can't be troubled to read an upgrade guide [1] don't deserve to have a functioning system?  To me, it seems awfully irresponsible to switch to a new profile that one knows nothing about.  If the user is irresponsible enough to do that, then who knows what other irresponsible things they might do?
> 
> Zac
> 
> [1] http://www.gentoo.org/doc/en/gentoo-upgrading.xml#doc_chap3

I think both our points are that there is a middle ground between 
screwing the user outright and holding their hand.  If you want to 
trumpet the change on forums, on www, on -announce, get the message out 
there; then I'd be more for a change like that.  The problem is last 
time it was dead silent; oh it's in the upgrade guide, great; we already 
know that not everyone reads it.  At that point you are just leaving the 
  pit for them to walk into.  IMHO, thats irresponsible of Gentoo as a 
whole.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Zac Medico]

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

Alec Warner wrote:
> Zac Medico wrote:
> I'm not sure what the probability of people hurting themselves like
> this is.  Perhaps it's a negligible corner case and a note in the
> upgrade guide will be enough to keep the vast majority of users on the
> right track.  I'd hope that a user would be wise enough to read some
> docs prior to switching to a new profile with a potentially outdated
> version of portage.
> 
> 
>> Damn your mail client ;)
> 
>> The past[1] has shown that users don't read docs.
> 
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=63400

Perhaps users that can't be troubled to read an upgrade guide [1] don't deserve to have a functioning system?  To me, it seems awfully irresponsible to switch to a new profile that one knows nothing about.  If the user is irresponsible enough to do that, then who knows what other irresponsible things they might do?

Zac

[1] http://www.gentoo.org/doc/en/gentoo-upgrading.xml#doc_chap3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE34N0/ejvha5XGaMRAqc/AJwIPuXZ+CddW9tledd4qR+KZKnXFACgirwN
igFjiUz38545d1Ng3OgSv4o=
=uCsk
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Donnie Berkholz]

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

Alec Warner wrote:
> I think both our points are that there is a middle ground between
> screwing the user outright and holding their hand.  If you want to
> trumpet the change on forums, on www, on -announce, get the message out
> there; then I'd be more for a change like that.  The problem is last
> time it was dead silent; oh it's in the upgrade guide, great; we already
> know that not everyone reads it.  At that point you are just leaving the
>  pit for them to walk into.  IMHO, thats irresponsible of Gentoo as a
> whole.

Yet another reason to finish up GLEP 42..


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

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Alec Warner]

Donnie Berkholz wrote:
> Alec Warner wrote:
> 
>>I think both our points are that there is a middle ground between
>>screwing the user outright and holding their hand.  If you want to
>>trumpet the change on forums, on www, on -announce, get the message out
>>there; then I'd be more for a change like that.  The problem is last
>>time it was dead silent; oh it's in the upgrade guide, great; we already
>>know that not everyone reads it.  At that point you are just leaving the
>> pit for them to walk into.  IMHO, thats irresponsible of Gentoo as a
>>whole.
> 
> 
> Yet another reason to finish up GLEP 42..
> 

Actually I was thinking of implementing glep 42 as a mini-project for 
treecleaners, but I need to finish SoC first.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: multiple inheritance support for profiles

[Christel Doty]

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

On Mon, 2006-08-14 at 07:28 -0400, Alec Warner wrote:
> Donnie Berkholz wrote:
> > Alec Warner wrote:
> > 
> >>I think both our points are that there is a middle ground between
> >>screwing the user outright and holding their hand.  If you want to
> >>trumpet the change on forums, on www, on -announce, get the message out
> >>there; then I'd be more for a change like that.  The problem is last
> >>time it was dead silent; oh it's in the upgrade guide, great; we already
> >>know that not everyone reads it.  At that point you are just leaving the
> >> pit for them to walk into.  IMHO, thats irresponsible of Gentoo as a
> >>whole.
> > 
> > 
> > Yet another reason to finish up GLEP 42..
> > 
> 
> Actually I was thinking of implementing glep 42 as a mini-project for 
> treecleaners, but I need to finish SoC first.

What an excellent idea.

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