Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On Wed, 21 Jan 2009 22:10:29 -0600 Jeremy Olexa darks...@gentoo.org wrote: I think the spec should just be upgraded because it isn't exactly obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We already have 3.1 features in the tree, I'm not sure where the red tape is here. The problem is, if the tree uses 3.1 and you don't have 3.1, it's a massive pain in the ass to upgrade. We waited a lng time between 3.0 going stable and allowing it in the tree because of that. Ideally we'd say no using 3.1 features unless EAPI=3, but that would be messy with eclasses even if developers did know that += is a 3.1 feature... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On Wed, 21 Jan 2009 16:02:29 -0800 Donnie Berkholz dberkh...@gentoo.org wrote: - PMS, bug #250077: Do we need to get involved in this? (-dev) The question for this one, really, is whether people are happy having such a vaguely specified utility whose behaviour keeps changing in ways that break existing idioms. If they are, at the very least we'd need a guarantee from the Portage people that they're not going to change its behaviour yet again, and ideally they'd revert the recent behaviour changes back to what stable Portage does. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On 16:11 Thu 22 Jan , Ciaran McCreesh wrote: On Wed, 21 Jan 2009 22:10:29 -0600 Jeremy Olexa darks...@gentoo.org wrote: I think the spec should just be upgraded because it isn't exactly obvious to the casual dev what is a 3.0 feature vs 3.1, etc. We already have 3.1 features in the tree, I'm not sure where the red tape is here. The problem is, if the tree uses 3.1 and you don't have 3.1, it's a massive pain in the ass to upgrade. We waited a lng time between 3.0 going stable and allowing it in the tree because of that. Ideally we'd say no using 3.1 features unless EAPI=3, but that would be messy with eclasses even if developers did know that += is a 3.1 feature... Can this be fixed by adding bash dependencies to things using new features? As long as we keep them out of the build path of bash, things ought to work. Then we could add a repoman check for new features, if we wanted. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpwr1JwKnCMC.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On Thu, 22 Jan 2009 08:56:23 -0800 Donnie Berkholz dberkh...@gentoo.org wrote: Can this be fixed by adding bash dependencies to things using new features? As long as we keep them out of the build path of bash, things ought to work. Only if you're guaranteed bash 3.1 on boxes that do metadata generation. Which means it won't work for overlays. Then we could add a repoman check for new features, if we wanted. Can't do that unless you write a feature-complete bash parser and pretend-execute every possible path an ebuild can take... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On Thu, Jan 22, 2009 at 5:02 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Only if you're guaranteed bash 3.1 on boxes that do metadata generation. Which means it won't work for overlays. Come to think of it... This is yet another reason GLEP 55 is necessary. -- Ciaran McCreesh
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On 17:02 Thu 22 Jan , Ciaran McCreesh wrote: On Thu, 22 Jan 2009 08:56:23 -0800 Donnie Berkholz dberkh...@gentoo.org wrote: Can this be fixed by adding bash dependencies to things using new features? As long as we keep them out of the build path of bash, things ought to work. Only if you're guaranteed bash 3.1 on boxes that do metadata generation. Which means it won't work for overlays. I'm not an expert on metadata generation, so please tell me if I'm wrong here. Most if not all overlays don't ship pregenerated metadata, which means users have to generate it locally. Without doing so, they cannot install anything from that overlay that uses bash features they lack. They can still install things from that overlay that don't use the new bash features. Consequently, packages in overlays using new bash features won't work till you upgrade your bash. They also won't be able to give you a good error about how to fix it, because you can't guarantee that you'll be able to parse the ebuild/eclass as far as the bash dependency. I guess a GLEP 42 news item would sort of work, but I really wish we had tree dependencies. Another option would be to make overlay maintainers generate their own metadata. Then we could add a repoman check for new features, if we wanted. Can't do that unless you write a feature-complete bash parser and pretend-execute every possible path an ebuild can take... We're getting into pretty weird territory here -- if you had slotted bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n foo.ebuild, etc. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpXs2xQuyFmH.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On Thu, 22 Jan 2009 09:28:31 -0800 Donnie Berkholz dberkh...@gentoo.org wrote: Only if you're guaranteed bash 3.1 on boxes that do metadata generation. Which means it won't work for overlays. I'm not an expert on metadata generation, so please tell me if I'm wrong here. Most if not all overlays don't ship pregenerated metadata, which means users have to generate it locally. Without doing so, they cannot install anything from that overlay that uses bash features they lack. They can still install things from that overlay that don't use the new bash features. Consequently, packages in overlays using new bash features won't work till you upgrade your bash. They also won't be able to give you a good error about how to fix it, because you can't guarantee that you'll be able to parse the ebuild/eclass as far as the bash dependency. It's the won't work bit that's the problem. Using bash-3.1 features with older bash won't generally give a fatal error. It'll just result in an easily missable message being shown to stderr, and the package carrying on with duff information. The failures can be extremely unobvious and can result in utterly h0rked packages being installed. I guess a GLEP 42 news item would sort of work, but I really wish we had tree dependencies. There're always profiles... But profiles have to be updated long before 3.1 features are in use, to give people time to upgrade. Another option would be to make overlay maintainers generate their own metadata. Probably not viable. Metadata generation moves hosting an overlay from something you do with a VCS to a complicated procedure involving several interacting tools -- it's complicated enough that even the way it's done for gentoo-x86 doesn't always work properly... We're getting into pretty weird territory here -- if you had slotted bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n foo.ebuild, etc. That still wouldn't catch a lot of things... Unfortunately repoman can't replace developer knowledge. Short of persuading upstream to add a feature that makes bash able to die if it detects you using features added in a version newer than the one you tell it, there's not much that can be done beyond educating developers, restricting newer bash features to newer EAPIs and using GLEP 55 to handle the metadata generation problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On 18:23 Thu 22 Jan , Tobias Scherbaum wrote: Donnie Berkholz wrote: Discuss on-list before meeting --- - Council meta stuff (-council) - Can the size change? Minimum? Maximum? - Should we have 2-year staggered terms? I'm in favor of a fixed size of council members, I'd like to see at least 5 council members *if* developers want to change the size. I dislike the idea of stretched 2-year terms, instead I prefer having 1-year staggered terms (voting every 6 months and replace 3 or 4 council members). This would allow to put open council slots into the next election, we wouldn't need to hold extra elections for open slots then. Anyways, this is something we can discuss - but as a change to the voting procedure most likely does change or extend what's written down in GLEP 39 I'd like to see a election on those changes. I replied to -council to keep this discussion off -dev. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpsDBxJ6LM3F.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
Ulrich Mueller wrote: On Thu, 22 Jan 2009, Tobias Scherbaum wrote: - PMS, bug #250077: Do we need to get involved in this? (-dev) We haven't been asked to get involved, therefore we don't need to. http://thread.gmane.org/gmane.linux.gentoo.devel/59321/focus=59324 well, http://article.gmane.org/gmane.linux.gentoo.devel/59428 We do have the procedure you did ask for and I personally tend to agree with what Donnie said. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On 15:35 Wed 21 Jan , Donnie Berkholz wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Here's what I've got: Discuss on-list before meeting --- - Council meta stuff (-council) - Can the size change? Minimum? Maximum? - Should we have 2-year staggered terms? - PMS, bug #250077: Do we need to get involved in this? (-dev) Meeting topics -- - Council meta stuff: What needs to happen before decisions? - Open bug review -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpRTPcWwa5Xv.pgp Description: PGP signature
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
Donnie Berkholz wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Sorry for the late request. Can we get a consensus on bash version in the tree? this thread[1] is unresolved. I understand that the PMS draft is not set in stone (or something), but please...let's progress and update the spec[2]. I feel that this makes it hard for other projects relying on Gentoo to do some things without being able to *know* what version of bash is allowed. Currently, our /draft/ says bash-3.0 but our tree says otherwise. [1]: http://thread.gmane.org/gmane.linux.gentoo.devel/59154 [2]: Or make the tree comply, I don't really care tbh.
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
On 21:28 Wed 21 Jan , Jeremy Olexa wrote: Can we get a consensus on bash version in the tree? this thread[1] is unresolved. I understand that the PMS draft is not set in stone (or something), but please...let's progress and update the spec[2]. I feel that this makes it hard for other projects relying on Gentoo to do some things without being able to *know* what version of bash is allowed. Which projects relying on Gentoo are having a hard time? It's helpful to know the impact of a problem when deciding what to do about it. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpeWfDIcAtvM.pgp Description: PGP signature
