Re: [gentoo-dev] Council meeting summary for 10 July 2008
В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? I've read all previous discussions but still miss answer to the question: Why is it impossible to state that .ebuild extension is for bash based ebuild make package manager get and filter EAPIs based on EAPI variable? Note, I assume that we can do not backward-compatible changes in PM, we just need to wait enough time to start using it. But taking into account that the features that will make use of this GLEP55 are still not so evident I don't see any problem to wait. In any case I'd like to understand why should we start support this hell of extensions. -- Peter.
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On 2008-07-20 17:38, Peter Volkov uttered these thoughts: В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? I've read all previous discussions but still miss answer to the question: Why is it impossible to state that .ebuild extension is for bash based ebuild make package manager get and filter EAPIs based on EAPI variable? Because that would still not allow global scope changes, because in order to get to know which EAPI the ebuild is written in, you have to actually source the ebuild, and by then it's too late. Unless you introduce some inane requirement that the EAPI variable has to be the first thing stated in the ebuild and force the PMs to extract that value before actually starting to parse the ebuild. Now, if _that's_ not an ugly solution, i don't know what is... You have to know _how_ to interpret an ebuild _before_ you actually start doing it. Note, I assume that we can do not backward-compatible changes in PM, we just need to wait enough time to start using it. But taking into account that the features that will make use of this GLEP55 are still not so evident I don't see any problem to wait. In any case I'd like to understand why should we start support this hell of extensions. Reasons for the change has been stated before, and the one i just explained is the main one so far as i know. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpG4XHQmlNIp.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Ciaran McCreesh kirjoitti: On Sun, 13 Jul 2008 16:16:23 -0700 Alec Warner [EMAIL PROTECTED] wrote: As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. You mean you don't want per-category/package eclasses, or eclasses that can indicate that they only work with some EAPIs, or eclasses that can indicate that they're being used incorrectly, or the death of EXPORT_FUNCTIONS? All of these have been discussed as desirable future extensions. Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 18:58:01 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Ciaran McCreesh kirjoitti: On Tue, 15 Jul 2008 18:58:01 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Yes I can think a lot of features like this that would be of great use in the main tree but as long as Portage is the only official and stable package manager and doesn't support the things you listed, the GLEP is not of much use. So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 19:16:42 +0300 Petteri Räty [EMAIL PROTECTED] wrote: So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. Why? We know it's a not-too-distant future need. Might as well get it out of the way now so there isn't more than an hour's worth of stuff all needing to be approved at the same time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Petteri Räty wrote: I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. In addition, I'd want to see why the particular approach suggested in this GELP is the only way (as some seem to claim). I have yet to be convinced of this, and as I've pointed out before (and do not wish to belabor further here), I believe there are major drawbacks to putting the EAPI in the filename/extension. Rushing to approve this GLEP would be a mistake, IMHO. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
Petteri Räty wrote: Ciaran McCreesh kirjoitti: So you're saying the GLEP's of no use until Portage supports them, but Portage can't support them until you say yes to the GLEP... I am saying that it makes sense to approve both at the same time or have other official package managers approved before accepting the GLEP. I'm not sure that implementation of new features in portage or official status for other package managers needs to be a condition for acceptance of this GLEP. The council's main concern was that there wasn't a clearly defined immediate need for the GLEP so it was sensible to defer it. That isn't an unreasonable suggestion. Would it be more constructive to create a list of new features/capabilities that depend on this GLEP. For each I'd define: 1. The feature/unmet need. 2. Why it can't be done or can only be done poorly without the new GLEP. 3. When we're likely to see the feature become available assuming the GLEP were approved. 4. What package managers are likely to implement it. (Ie their maintainers endorse the need. It sounds like this list might already have some items on it - so why not document them? If the council wants to avoid approving the GLSA for a merely theoretical need they might offer to endorse the idea but delay it pending the implementation of one or more of the new features in one, two, or all three major package managers, or pending support by portage. That would give developers some assurance that they wouldn't waste time going down a road only to be shot down later. It is good for the well-being of Gentoo that the council be relatively conservative with regard to potentially-disruptive decisions. They simply want to see that the benefits outweigh the costs. So, just show them the benefits. At some point the case for going forward outweighs the reluctance to do so. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Tue, 15 Jul 2008 13:58:36 -0400 Richard Freeman [EMAIL PROTECTED] wrote: Would it be more constructive to create a list of new features/capabilities that depend on this GLEP. For each I'd define: 1. The feature/unmet need. 2. Why it can't be done or can only be done poorly without the new GLEP. 3. When we're likely to see the feature become available assuming the GLEP were approved. 4. What package managers are likely to implement it. (Ie their maintainers endorse the need. It sounds like this list might already have some items on it - so why not document them? The GLEP already documents what needs it, in the broadest reasonable terms. The problem with specifics is that everyone will then start arguing about how exactly, say, per-cat/pkg eclasses would work, which is irrelevant to the GLEP. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, Jul 14, 2008 at 5:32 AM, Jeroen Roovers [EMAIL PROTECTED] wrote: What GLEP 55 fails to address right now is the very development process it is seemingly supposed to alleviate. It addresses the issue of EAPI implementation from the viewpoint of the package manager's developer, but it doesn't begin to address the viewpoint of the package maintainer or architecture developer at all. It looks to me like a lot of problems are moved out of the package manager(s) and into this already huge tree of files, with different EAPI-suffixed files addressing different problems, and that indicate be a non-trivial increase in the number of files in the tree - files which would address the equal purpose of installing exactly one =cat/pkg-ver. GLEP 55 says: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. In other words, disregarding its other real world deficiencies like an immediate goal, GLEP 55 fails to describe a keywording policy for architecture developers Keywording policy wouldn't change. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 05:32:58 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: I'm sorry to say this, but I actually do take offence at most things you write. Perhaps you should consider what that indicates about yourself, rather than about me. As you know fine well, implementing what clearly should be Please stop assuming people know everything you know and/or that people should know everything you know. This is a public forum where you should undertake to explain yourself fully instead of referring vaguely to an unknown set of morals and then suggesting another party should address whatever conflicts with that. It is a particularly subtle variant of the classic straw man that you regularly wield, and it is one of those things that often makes me take offence at what you write. All I'm assuming is that people have read and understood the GLEP, and in any places where they don't understand, they ask. Is that assuming too much? package manager provided functionality as hacks in an ebuild is never going to give a nice, elegant solution. However, if package manager functionality isn't available and can't become available quickly, it might be the only solution until such functionality can come along. So it's not doing them badly, it's currently the only solution and you haven't provided any arguments against this only solution as yet. No, it is doing it badly. A square wheel is bad, even if it was necessary because the round one was unattainable. In other words perhaps, is it your opinion that GLEP 55 needs to be implemented because sys-libs/glibc requires an immediate rewrite? Are there any bug reports that would be good examples of why this new implementation is warranted? GLEP 55 wouldn't even allow an immediate rewrite of glibc because new EAPIs can't easily be used on system packages. Oh. You just shot down your only real world example (eblit versus GLEP 55). If you have any more, I'd happily have a look at them, as would anyone else worrying about the consequences of having GLEP 55 implemented. Uh. Future versions of glibc? Read what I wrote. So no. Instead, GLEP 55 would allow a future EAPI to introduce a proper per-package eclass-like solution at the package manager level, which could then over time be phased into glibc, and over less time be phased into other packages that would make use of it. That's the nice thing about the GLEP -- it allows the phased introduction of a larger class improvements without major upheaval. [Class _of_ improvements, I guess.] Please provide an example of what that process would look like. You've always been good at these we have ebuild 1, then ebuild 2 comes along, depending on ebuild 3 [...] games, so please explain what we'd end up with in a hypothetical GLEP 55 compliant gentoo-x86/sys-libs/glibc, with build files (formerly ebuilds) getting added, removed, keyworded, package.masked and so on. New, experimental glibc versions that aren't expected to go stable quickly use the new EAPI. Existing versions and any will need to go stable soon bumps stay using the old EAPI. After the next release (which is *only* an issue for dependencies of the package manager) all new glibc versions use the new EAPI. What _I_ envision now is a motley crew of EAPI suffixed build files processing through gentoo-x86/sys-libs/glibc over time. Surely it would look a right mess every time you needed to go into that directory (particularly not in a role as any package manager's user or developer, but as a build file developer browsing through those files). How does: $ ls ChangeLog glibc-2.3.6-r4.ebuild glibc-2.5.1.ebuild Manifestglibc-2.3.6-r5.ebuild glibc-2.6.1.ebuild files glibc-2.4-r4.ebuildglibc-2.6.ebuild glibc-2.2.5-r10.ebuild glibc-2.5-r2.ebuildglibc-2.7-r2.ebuild glibc-2.3.2-r12.ebuild glibc-2.5-r3.ebuild glibc-2.8_p20080602.ebuild-2 glibc-2.3.5-r3.ebuild glibc-2.5-r4.ebuildmetadata.xml look any worse than what's there now? What GLEP 55 fails to address right now is the very development process it is seemingly supposed to alleviate. It addresses the issue of EAPI implementation from the viewpoint of the package manager's developer, but it doesn't begin to address the viewpoint of the package maintainer or architecture developer at all. It looks to me like a lot of problems are moved out of the package manager(s) and into this already huge tree of files, with different EAPI-suffixed files addressing different problems, and that indicate be a non-trivial increase in the number of files in the tree - files which would address the equal purpose of installing exactly one =cat/pkg-ver. GLEP 55 does not change the EAPI process from a maintainer perspective, except that it replaces set EAPI=X in the ebuild with use .ebuild-X. In other words, disregarding its other real world deficiencies like an immediate goal, GLEP 55 fails
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Betelgeuse@ dberkholz: with GLEP 55 EAPI X can add the support for scm Betelgeuse@ dberkholz: and older Portage versions work just fine I thought we established that EAPI (no matter how it's defined) only controls ebuild _contents_ ... Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, but that's unclear until it's been revised. Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, but that's unclear until it's been revised. Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? I understood both. As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. -- Ciaran McCreesh -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 4:16 PM, Alec Warner [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 13 Jul 2008 00:11:18 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, but that's unclear until it's been revised. Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? I understood both. As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. ugh, s/who// -- Ciaran McCreesh -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 16:16:23 -0700 Alec Warner [EMAIL PROTECTED] wrote: As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. You mean you don't want per-category/package eclasses, or eclasses that can indicate that they only work with some EAPIs, or eclasses that can indicate that they're being used incorrectly, or the death of EXPORT_FUNCTIONS? All of these have been discussed as desirable future extensions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, Jul 13, 2008 at 4:21 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sun, 13 Jul 2008 16:16:23 -0700 Alec Warner [EMAIL PROTECTED] wrote: As far as could be determined by the members at the meeting there no compelling examples in Gentoo who to change or add global scope functions in future EAPIs. As such those problems as stated are not in scope for Gentoo because Gentoo is not attempting to do those things at this time. You mean you don't want per-category/package eclasses, or eclasses that can indicate that they only work with some EAPIs, or eclasses that can indicate that they're being used incorrectly, or the death of EXPORT_FUNCTIONS? All of these have been discussed as desirable future extensions. I don't require any of those things, but maybe other people do and If so; they should probably come to the meeting or otherwise make themselves known because they were not at the previous meeting. The GLEP as written is not convincing; it doesn't say 'I am trying to do X with Gentoo and cannot because of this restriction.' It says 'In the future someone may want to do X and they won't be able to because of this restriction so lets try to remove the restriction now.' This is an admirable goal mind you; but it is my opinion that there are more concrete features that we could implement for benefits now rather than talk about what could be. I chatted briefly with peper on IRC about this (as he was the original GLEP author) so when he gets time he said he had some examples to provide. -- Ciaran McCreesh -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Sun, 13 Jul 2008 16:37:35 -0700 Alec Warner [EMAIL PROTECTED] wrote: I don't require any of those things, but maybe other people do and If so; they should probably come to the meeting or otherwise make themselves known because they were not at the previous meeting. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/ I presume you're aware of that. People are already doing those other things, and doing them badly, because there's currently no other option. This isn't some hypothetical future requirement. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 00:43:06 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: People are already doing those other things, and doing them badly, because there's currently no other option. This isn't some hypothetical future requirement. When you wrote doing them badly, did you mean to imply doing something else than GLEP 55, or were you just slagging off whoever implemented eblits in sys-libs/glibc? In other words perhaps, is it your opinion that GLEP 55 needs to be implemented because sys-libs/glibc requires an immediate rewrite? Are there any bug reports that would be good examples of why this new implementation is warranted? JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, 14 Jul 2008 03:13:44 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008 00:43:06 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: People are already doing those other things, and doing them badly, because there's currently no other option. This isn't some hypothetical future requirement. When you wrote doing them badly, did you mean to imply doing something else than GLEP 55, or were you just slagging off whoever implemented eblits in sys-libs/glibc? As much as you like to try to find some way of taking offence at everything I write, no, there's no slagging off in there. As you know fine well, implementing what clearly should be package manager provided functionality as hacks in an ebuild is never going to give a nice, elegant solution. However, if package manager functionality isn't available and can't become available quickly, it might be the only solution until such functionality can come along. And making sure such functionality can come along is at least partly the Council's responsibility. In other words perhaps, is it your opinion that GLEP 55 needs to be implemented because sys-libs/glibc requires an immediate rewrite? Are there any bug reports that would be good examples of why this new implementation is warranted? GLEP 55 wouldn't even allow an immediate rewrite of glibc because new EAPIs can't easily be used on system packages. So no. Instead, GLEP 55 would allow a future EAPI to introduce a proper per-package eclass-like solution at the package manager level, which could then over time be phased into glibc, and over less time be phased into other packages that would make use of it. That's the nice thing about the GLEP -- it allows the phased introduction of a larger class improvements without major upheaval. -- Ciaran McCreesh signature.asc Description: PGP signature
