Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
On Sat, 2006-10-07 at 23:19 -0500, Andrew Gaffney wrote: Should we add multiple inheritance support now? The changes necessary to add this support are minimal and we can have this feature in portage-2.1.2 [3], which I estimate will be ready for a final release in approximately 3 to 5 weeks. Are you proposing just adding the support or creating the new profiles as well? If it's just the support, adding it into portage now certainly won't hurt anything (unless someone really fscks up the current single-parent cascaded profiles in the tree) and is probably a good idea. If you're talking about putting together the new profiles now as well, is it going to be a separate profile tree (much as default-linux/ was created for cascaded profiles)? Will it be directly under profiles/? default-linux/? I have a set of profiles already (to replace default-linux) that use default/linux as the base. It can live side-by-side with the current profiles quite easily. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for your feedback, everyone. I've gone ahead and enabled multiple inheritance in portage-2.1.2_pre2-r7. I would appreciate it if people would start experimenting with it (of course, please don't use multiple inheritance in the live tree in ways that will hurt users of the current single inheritance profiles). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKqiW/ejvha5XGaMRAjl3AKCwhjRcXibtTsk0DANsusiBcbfJnwCg5btA ybwPzQvwyyXXafRic+Habyo= =8P/q -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Zac Medico wrote: (of course, please don't use multiple inheritance in the live tree in ways that will hurt users of the current single inheritance profiles). If someone does, can we blame you? :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Andrew Gaffney wrote: Zac Medico wrote: (of course, please don't use multiple inheritance in the live tree in ways that will hurt users of the current single inheritance profiles). If someone does, can we blame you? :) Don't blame the tool, blame the tool using the tool improperly. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
On Saturday 07 October 2006 23:04, Zac Medico wrote: Should we add multiple inheritance support now? yes -mike pgpJagfj7FpY3.pgp Description: PGP signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Hi Zac, On 10/8/06, Zac Medico [EMAIL PROTECTED] wrote: I'm only proposing that we add support to portage now because it seems like it will be useful in the future. How and when people make use of this support does not concern me much. Zac I believe that multiple parent support would be useful for the Seeds project; it would allow the LAMP Developer Desktop (for example) to inherit from both the generic 2006.1/x86 profile and the LAMP Server profile. I'm not saying we'd definitely end up going that way, but it would be something worth testing when the time comes. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Am Sonntag, 8. Oktober 2006 12:05 schrieb Stuart Herbert: Hi Zac, On 10/8/06, Zac Medico [EMAIL PROTECTED] wrote: I'm only proposing that we add support to portage now because it seems like it will be useful in the future. How and when people make use of this support does not concern me much. Zac I believe that multiple parent support would be useful for the Seeds project; it would allow the LAMP Developer Desktop (for example) to inherit from both the generic 2006.1/x86 profile and the LAMP Server profile. Well, once we have that support the structure of profiles will radically change. The following is also something I'd like to be done while i'm in council. This is why i asked Zac to send the RFC to gentoo-dev. Thanks Zac :-) I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. profiles +-obsolete, which contains the old cascaded profiles. Let's remove | the current obsolete/ contents. | +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like nptl nptlonly here | +-amd64-linux, inherits default-linux/, base/amd64; standalone | +-amd64-hardened, inherits hardened, base/amd64; standalone | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; standalone This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. The Seeds project could do something like this: +-Seeds | +-amd64-lamp, inherits releases/2006.1/amd64-hardened and adds lamp specific useflags/packages. But i lack knowledge here. Stuart? Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Danny van Dyk wrote: I for one favour a more flattened profiles/ and a way to mark a profile as 'not standalone', similar to a deprecated file, that isn't inherited, to stop users biting their own asses. The following sample is not complete, but should give the right impressions. By 'not standalone', I assume you mean this profile does not work by itself, and is only meant to be inherited by other profiles. If that's not what you meant, we also need something that does that :) profiles +-obsolete, which contains the old cascaded profiles. Let's remove | the current obsolete/ contents. Doing this will break portage for people who are using old cascaded profiles. Portage would freak out if there wasn't a profile where there was one before, and there wouldn't be a way to do a 'deprecated' file to tell them about the new ones. +-default-linux, minimal default useflags here | | | +-linux-2.4, would be handy for x86 :-) amd64 has no supported 2.4 | kernel. | +-hardened, minimal default useflags here | +-default-bsd, minimal default useflags here | | | +fbsd, inherits default-bsd/ | +-base | | | +amd64, inherits base/ | +-releases | +-2006.1, does not inherit anything, stuff like nptl nptlonly here | +-amd64-linux, inherits default-linux/, base/amd64; standalone | +-amd64-hardened, inherits hardened, base/amd64; standalone | +-amd64-fbsd, inherits default-bsd/fbsd/, base/amd64; standalone This is a hot shot and I'm waiting for comments. Wolf? Agaffney? I can't really comment on the structure, since I don't really do much with profiles myself (no gentoo-x86 commit access). I'm prepared to do the work here and, as this new layout would take some time, it should be done in a seperate repository for the time being. Not necessary. It can just be a separate directory tree under profiles/ much like default-linux/ was created for cascaded profiles originally, and they can all be marked as deprecated or something. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
Zac Medico wrote: Some of you may recall that I proposed the addition of multiple inheritance to profiles a couple of months ago [1]. The idea is to extend the parent file in profiles so that it supports any number of parents (one per line). Parents listed closer to the bottom of the file will have the ability to override the settings of those listed nearer the top of file. As of portage-2.1 (included in the 2006.1 release media), portage will automatically generate an error if it encounters multiple inheritance (earlier versions would simply ignore anything after the first parent). As long as users follow the profile updating instructions [2] and update portage prior to a profile update, they won't have any trouble. However, if a user has =portage-2.0* and fails to follow the upgrade instructions, portage may attempt to build and install packages without the entire profile being correctly parsed. Should we add multiple inheritance support now? The changes necessary to add this support are minimal and we can have this feature in portage-2.1.2 [3], which I estimate will be ready for a final release in approximately 3 to 5 weeks. Are you proposing just adding the support or creating the new profiles as well? If it's just the support, adding it into portage now certainly won't hurt anything (unless someone really fscks up the current single-parent cascaded profiles in the tree) and is probably a good idea. If you're talking about putting together the new profiles now as well, is it going to be a separate profile tree (much as default-linux/ was created for cascaded profiles)? Will it be directly under profiles/? default-linux/? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project Today's lesson in political correctness: Go asphyxiate on a phallus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles, Round 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: Are you proposing just adding the support or creating the new profiles as well? If it's just the support, adding it into portage now certainly won't hurt anything (unless someone really fscks up the current single-parent cascaded profiles in the tree) and is probably a good idea. I'm only proposing that we add support to portage now because it seems like it will be useful in the future. How and when people make use of this support does not concern me much. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFKIE5/ejvha5XGaMRApbxAJ94JjcRroZFUcwwkWEDbNtw4J+fXQCeJGH0 KlPrgI4NoVJKSKMFnjKuQVA= =swdD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
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
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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
-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
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 pgpNk7UrGZW8u.pgp Description: PGP signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
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
On Sun, 13 Aug 2006 13:01:41 -0400 Alec Warner [EMAIL PROTECTED] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
-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
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
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.. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED] 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 wrote: On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED] 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
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
On Sat, 12 Aug 2006 16:11:25 -0400 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED] | 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
Ciaran McCreesh wrote: On Sat, 12 Aug 2006 16:11:25 -0400 Alec Warner [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Sat, 12 Aug 2006 13:24:49 -0700 Zac Medico [EMAIL PROTECTED] | 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
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 Gaffneyhttp://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 wrote: On Sat, 12 Aug 2006 16:54:41 -0500 Andrew Gaffney [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Alec Warner wrote: Ciaran McCreesh wrote: On Sat, 12 Aug 2006 16:54:41 -0500 Andrew Gaffney [EMAIL PROTECTED] 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
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 pgpIQo9yB5XK1.pgp Description: PGP signature
Re: [gentoo-dev] RFC: multiple inheritance support for profiles
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
