Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote:
/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles.
Again, a detail of how Portage is configured. PMS only covers profiles that
are in repositories - it's up to the package manager how to deal with ones
that are elsewhere.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Saturday 22 August 2009, Chip Parker wrote: 2009/8/21 Robert Buchholz r...@gentoo.org: On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert When the PMS subproject is overwhelmingly ruled by a single person who doesn't have official Gentoo developer status and yet it is allowed to remove features from portage (the reference implementation) that predated PMS at the direction of this same non-dev, you start to have a very big problem. If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS, had instead been added yesterday, I would completely agree that we should revert it and it should be part of a future specification. Since this is instead a situation where the blueprints were wrong and the builder was correct, let's not go throwing away our normal sized doors. Since I, as well as the only person who's loudly having an issue with portage and PMS not matching up in this respect, are both USERS and NOT Gentoo developers, it's my opinion that portage should be left alone and PMS should be corrected to align with the spirit, if not the letter of what was documented WELL after the initial commit that added the feature. And, since I and the main contributor to PMS are both users, it's also my opinion that NEITHER of us should have anything to do with the policy/specification defining package manager behavior for the most prolific package manager in use today. Could all of you just let this go. In this case Ciaran is actually right. Furthermore, From the beginning of the project there has been behaviour which was technically allowed but not condoned for official packages. The more formalized approach with EAPI/PMS is no different. Now this thread is too long already, just shut up about it. If you find the portage behaviour desirable and want it allowed in the tree. Well, EAPI is the way to go. Remember EAPI is not established by Ciaran, but by the council. Paul -- Paul de Vrieze Email: pau...@gentoo.org
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Am Samstag, den 22.08.2009, 01:54 +0100 schrieb AllenJB: From what I've seen here, at least part of the problem here stems from the fact that this feature won't be considered until EAPI-4, and that means it might be a long way off yet. This, in my mind, raises the question of whether the current PMS/EAPI process is too slow in certain circumstances and could it be modified to speed things up when deemed necessary? Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? If this is a matter of what the council has decided, would a simple solution be to have a motion for amendment / fast-track of EAPI2.1 (or alternative solution) brought up and voted on by the council? As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Tiziano Müller wrote: As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano I agree with what's being said here. The previous council ran into a huge road block with EAPI and GLEP's. I think that EAPI's should be moved to the Portage herd, and GLEPs assigned as necessary until final approval or dissent is given by the council. This would hopefully reduce contention with GLEP's as has happened in the past, and put EAPI's closer to the devs who will implement them. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On 8/22/09, Andrew D Kirch trel...@trelane.net wrote: Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. If it wasn't a sort of a bug (some omission in the original PMS?), then I suppose this could also be described as The Three 'E's: embrace (a supposed standard), extend (possibly in an incompatible, hard to replicate ways), and extinguish (well, harder to do with FLOSS, but you can probably see where I got these 'e's ;) ). I think that also Microsoft calls that 'innovation'. :D Let's just leave this to the Council. These semantic-pedantic is not, is too-discussions with Mr. McCreesh never seem to end as both sides keep to the logic that if you don't quickly reply to comments which are wrong, then your silence means that the other one was right. There should be some kind of eternal loop detection for these threads ... :P -- Arttu V.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Am Samstag, den 22.08.2009, 02:23 -0400 schrieb Andrew D Kirch: Tiziano Müller wrote: As you can see currently, most time is needed to implemente the features in portage. It therefore doesn't make sense to make the EAPI process even faster. On the other hand, I think it would make sense to have a separate group developing new EAPIs instead of the council. Cheers, Tiziano I agree with what's being said here. The previous council ran into a huge road block with EAPI and GLEP's. I think that EAPI's should be moved to the Portage herd, Portage just happens to be one of the package managers to implement the specs afterwards. Since you agree with me about implementation taking too long a pretty easy conclusion is that the portage team is already understaffed so moving even more responsibility/work there makes the whole process even slower. (Besides the fact of not including other package manager devs in the process, but guessing from your earlier comments you don't care about that.) and GLEPs assigned as necessary until final approval or dissent is given by the council. And you moaned about bureaucracy earlier today? Interesting. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 01:54:22 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? It's a possibility, since it's zero cost for Portage and an easy one to word into the specification. Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. Zac said three months ago that Portage EAPI 3 support would be done in a month, so it can't be far off ready. We also need to consider whether people even want it done exactly the way Portage does it now. Some developers have expressed a preference for a package.mask.d of some kind instead. So yes, it's something that could be done, if the Council is interested and if it's not going to be used as an excuse to try to shove a whole load of other things through at the same time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-22 21:39:47 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 01:54:22 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: Could there be room for fast track EAPI's to be considered on some occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with the package.* as directory in profiles feature included? It's a possibility, since it's zero cost for Portage and an easy one to word into the specification. Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing bash-4.0 features). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 22:22:54 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Another possibly nicer option would be to add the feature into EAPI 3. However, if we're considering this, we'd have to be absolutely totally clear that this isn't a call to open up EAPI 3 for yet more changes. EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing bash-4.0 features). That isn't a trivial implementation feature unless GLEP 55 is passed, since it breaks sourcing for metadata for users of older Portage versions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 14:47:44 -0700 Chip Parker infowo...@gmail.com wrote: * When loading profiles '/etc/make.profile' for repository 'gentoo': /etc/make.profile is user configuration, and beyond the scope of PMS. Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. It is impossible to include absolute paths in repository parent files, since there is no guaranteed filesystem location for repositories. This is now the third time I've had to tell you that user configuration is not part of PMS. You're contributing substantially to the amount of noise on the subject, wasting the time of everyone who has to read your posts and respond to them. Kindly stop. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, Aug 21, 2009 at 5:34 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS As I've already explained to you on bugzilla, this is untrue. You're confusing user configuration with the tree. PMS has nothing to say about user configuration, and nothing is being done to take away the feature you're concerned about. -- Ciaran McCreesh This assertion is not only incorrect but asinine. build paludis # paludis -q apache palu...@1250977472: [WARNING e.ebuild.configuration.no_names_cache] The names_cache key is not set in '/etc/paludis/repositories/gentoo.conf'. You should read the Paludis documentation and select an appropriate value. Unhandled exception: * In program paludis -q apache: * When performing query action from command line: * When handling query 'apache': * When parsing user package dep spec 'apache': * When parsing generic package dep spec 'apache': * When disambiguating package name 'apache': * When finding all versions in some arbitrary order from packages matching */apache with filter all matches filtered through all matches: * When finding category names containing package 'apache': * When loading names for virtuals repository: * When loading virtual packages for repository 'gentoo' * When loading profiles '/etc/make.profile' for repository 'gentoo': * When using directory '/etc/make.profile': * When adding profile directory '/etc/make.profile: * When handling parent file for profile directory '/etc/make.profile: * When adding profile directory '/etc/managed-portage/common/pre/make.profile: * When loading specised use file '/etc/managed-portage/common/pre/make.profile/package.use: * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. This shows that both the PMS spec and your pet package manager are incapable of supporting behavior that was considered correct by portage prior to your initial RFC.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, Aug 22, 2009 at 2:52 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Sat, 22 Aug 2009 14:47:44 -0700 Chip Parker infowo...@gmail.com wrote: * When loading profiles '/etc/make.profile' for repository 'gentoo': /etc/make.profile is user configuration, and beyond the scope of PMS. Additionally, I plan to show very soon that PMS is incorrect in its requirement that profiles/parent includes only relative paths. It is impossible to include absolute paths in repository parent files, since there is no guaranteed filesystem location for repositories. This is now the third time I've had to tell you that user configuration is not part of PMS. You're contributing substantially to the amount of noise on the subject, wasting the time of everyone who has to read your posts and respond to them. Kindly stop. -- Ciaran McCreesh Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. '/etc/managed-portage/common/pre/make.profile/package.use: * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) This is the exact same error that I get either when using the portage compatibility OR paludis with my profile defined in the only configuration file type where it is allowed to go (on my system /etc/paludis/repositories/gentoo-portage.conf), as per the paludis documentation. (http://paludis.pioto.org/configuration/repositories/e.html) build managed-portage # paludis -q apache palu...@1250986148: [WARNING portage_environment.dodgy] Use of Portage configuration files will lead to sub-optimal performance and loss of functionality. Full support for Portage configuration formats is not guaranteed; issues should be reported via trac. Unhandled exception: snip repeat of previous email output * In file '/etc/managed-portage/common/pre/make.profile/package.use': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError) So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. If you can show me a DOCUMENTED configuration option for including a profiles/ directory for use with paludis that is outside of defining it in a repositories/*.conf file, and it's tested working, I'll gladly be quiet and go away. Otherwise, I will continue to loudly object to you attempting to break my systems.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 01:26:24 Chip Parker wrote: So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. You're still talking about /etc, which is still unaffected by PMS. If Paludis doesn't support a feature in /etc that you want to use, then feel free to file a bug. If Portage supports that feature in /etc, there's no reason why it needs to stop doing so, regardless of what it does or doesn't accept in the tree.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 17:26:24 -0700 Chip Parker infowo...@gmail.com wrote: Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. I showed you the relevant portion. /etc/make.profile means it is user configuration, which in turn means PMS has absolutely nothing to say about it. Anything done under /etc/make.profile is entirely up to the package manager and is not covered by the specification. So for the fourth time, no-one has asked for anything that will break what you're doing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, Aug 22, 2009 at 5:32 PM, David Levertonlevert...@googlemail.com wrote: On Sunday 23 August 2009 01:26:24 Chip Parker wrote: So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. You're still talking about /etc, which is still unaffected by PMS. If Paludis doesn't support a feature in /etc that you want to use, then feel free to file a bug. If Portage supports that feature in /etc, there's no reason why it needs to stop doing so, regardless of what it does or doesn't accept in the tree. They're the same thing. It doesn't matter if the profiles directory is in located in /tmp or in /usr/local/portage, the behavior of paludis *still* doesn't support the feature that these profiles depend on and portage still *HAS* since before PMS was submitted to this list as an RFC in August of 2006. The argument here is that PMS should be changed to reflect what has been being used in the wild since before it came into existence, especially considering the removal of the particular feature that this trick depends on would break user expected behavior. On Sat, Aug 22, 2009 at 5:34 PM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: On Sat, 22 Aug 2009 17:26:24 -0700 Chip Parker infowo...@gmail.com wrote: Since you have a habit of ignoring relevant bits of technical opposition to some of your more insane schemes, I'll cite *again* the relevant portion. I showed you the relevant portion. /etc/make.profile means it is user configuration, which in turn means PMS has absolutely nothing to say about it. Anything done under /etc/make.profile is entirely up to the package manager and is not covered by the specification. So for the fourth time, no-one has asked for anything that will break what you're doing. You claim that PMS doesn't matter outside of a repository, and yet it most certainly does, because as I said to David, it doesn't matter /where/ the profiles are actually located: /etc/, /tmp/, /usr/local/portage/, or /usr/portage/ the behavior *should* be both consistent and not unnecessarily restricted by a specification controlled by a person who is on the outside of the Gentoo organization. If you'd prefer, I can merge my /etc/managed-portage stuff with my internal overlay and then bitch loudly about you attempting to remove features that existed prior to your involvement in Gentoo's package managers. Additionally, there isn't a way to define in paludis where the profiles actually exist outside of the repository configuration files, which means that in your mind, they're one and the same. What you proposed in the bug you filed would specifically break how I do things, without replacing it with an equal or better solution. Your inability or unwillingness to comprehend that simple fact is really not my concern. When the most prolific committer to PMS also happens to the most prolific committer and is listed as owning the repository for a competing package manager, it looks suspiciously like conflict of interest.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sat, 22 Aug 2009 18:10:36 -0700 Chip Parker infowo...@gmail.com wrote: What you proposed in the bug you filed would specifically break how I do things, without replacing it with an equal or better solution. No it wouldn't. It would have no effect whatsoever on how you do things. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 02:10:36 Chip Parker wrote: They're the same thing. It doesn't matter if the profiles directory is in located in /tmp or in /usr/local/portage, the behavior of paludis *still* doesn't support the feature that these profiles depend on and portage still *HAS* since before PMS was submitted to this list as an RFC in August of 2006. The behaviour of Paludis doesn't matter as far as your own /etc goes, because you (presumably) don't use Paludis. You're free to use whatever's supported by your own favourite package manager. Additionally, there isn't a way to define in paludis where the profiles actually exist outside of the repository configuration files, which means that in your mind, they're one and the same. You can read minds now? The actual reason why the profile is configured in the repository configuration file is that the profile used by a particular repository's packages is a parameter to that repository. Not that that's relevant to what you do in your own /etc, as I said above.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-23 02:34:08 Ciaran McCreesh napisał(a):
On Sat, 22 Aug 2009 17:26:24 -0700
Chip Parker infowo...@gmail.com wrote:
Since you have a habit of ignoring relevant bits of technical
opposition to some of your more insane schemes, I'll cite *again* the
relevant portion.
I showed you the relevant portion. /etc/make.profile means it is user
configuration, which in turn means PMS has absolutely nothing to say
about it. Anything done under /etc/make.profile is entirely up to the
package manager and is not covered by the specification.
/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles. Documentation of /etc/make.profile concerns also
all profile directories.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009/8/21 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. No. Changing the documentation does not retroactively change existing EAPIs.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-21 23:17:56 Ryan Hill napisał(a): On Fri, 21 Aug 2009 16:25:35 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-08-13 07:55:22 Ryan Hill napisał(a): On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. How does changing the portage documentation magically add this to the PMS? PMS developers are unwilling to fix many bugs in PMS. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 23:42:11 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: How does changing the portage documentation magically add this to the PMS? PMS developers are unwilling to fix many bugs in PMS. This is not a bug in PMS. PMS accurately reflected the Portage documentation at the time it was written and at the time it was approved. In addition, there was no real world use of this feature so there was no grounds to consider making it part of the specification despite it being undocumented. Thus, the way PMS was written was correct. What you are asking for would be like retroactively updating the HTML 4 specification to mandate a particular undocumented quirk of Internet Explorer 6's behaviour. The correct way to proceed is to use EAPI 4 to move this to be a specified feature, and to permit it only for profiles marked as using EAPI 4. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Friday 21 of August 2009 23:46:38 Ciaran McCreesh wrote: On Fri, 21 Aug 2009 23:42:11 +0200 PMS accurately reflected the Portage documentation at the time it was written and at the time it was approved. Agreed, but I think it was supposed to reflect Portage 'behaviour' at the time. Of course it's hard to blame anyone for it, especially after all these years. The correct way to proceed is to use EAPI 4 to move this to be a specified feature, and to permit it only for profiles marked as using EAPI 4. It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009/8/21 Robert Buchholz r...@gentoo.org: On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert When the PMS subproject is overwhelmingly ruled by a single person who doesn't have official Gentoo developer status and yet it is allowed to remove features from portage (the reference implementation) that predated PMS at the direction of this same non-dev, you start to have a very big problem. If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS, had instead been added yesterday, I would completely agree that we should revert it and it should be part of a future specification. Since this is instead a situation where the blueprints were wrong and the builder was correct, let's not go throwing away our normal sized doors. Since I, as well as the only person who's loudly having an issue with portage and PMS not matching up in this respect, are both USERS and NOT Gentoo developers, it's my opinion that portage should be left alone and PMS should be corrected to align with the spirit, if not the letter of what was documented WELL after the initial commit that added the feature. And, since I and the main contributor to PMS are both users, it's also my opinion that NEITHER of us should have anything to do with the policy/specification defining package manager behavior for the most prolific package manager in use today.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS As I've already explained to you on bugzilla, this is untrue. You're confusing user configuration with the tree. PMS has nothing to say about user configuration, and nothing is being done to take away the feature you're concerned about. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ryan Hill wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? Package managers can implement whatever extra bells and whistles they like, but they still have to follow the spec. Your metaphor is flawed in that you're talking about a single house here. If it doesn't match the plan you do an as-built and file a deviation with the registrar. The situation here is more like if you build a hundred houses to code, and then one above code, and then change code to match the one house and bulldoze the rest for not meeting minimal requirements. You're punishing anyone who implements a package manager to spec if you keep changing the spec in incompatible ways. Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. We've had a lot of political systems which try to implement a design which weeds out both the mediocre, and the excellent, leaving us with the average all have been failures. The reason why they fail is that it is the above average who do the heaviest lifting. Andrew D Kirch Funtoo.org
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill: On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? What I've really wanted for a long time is different package.mask files for different types of masks. eg. package.mask/broken.mask (qa.mask?) package.mask/removal.mask package.mask/security.mask package.mask/testing.mask To avoid collision with the current package.mask I'd prefer package.mask.d/ for the directory. Also makes the transition easy since we can generate package.mask out of the files in package.mask.d/. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Wed, 12 Aug 2009 23:55:22 -0600 Ryan Hill dirtye...@gentoo.org wrote: That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? Yup. We based the PMS wording upon the Portage documentation and the commit message that introduced the feature, both of which explicitly say it's only for /etc/portage/ use, not tree use. Portage's support for directories like that in the tree is an undocumented fluke caused by using the same code for user and tree configuration parsing without adding extra strictness checks for the tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thu, 13 Aug 2009 12:50:26 + (UTC) Mark Bateman coul...@soon.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarabeus at gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Except this stuff as directory was pre-EAPI and thus the PMS should have captured that as EAPI-1 Ergo PMS is wrong and needs to be updated to refect reality PMS accurately reflects the Portage documentation and the commit message that introduced the feature -- it's purely for use in /etc/portage/, which is beyond the scope of PMS. It is not the business of PMS to enforce undocumented features that Portage supports only by accident and that aren't used in the tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thu, Aug 13, 2009 at 4:05 PM, Tiziano Müllerdev-z...@gentoo.org wrote: To avoid collision with the current package.mask I'd prefer package.mask.d/ for the directory. Also makes the transition easy since we can generate package.mask out of the files in package.mask.d/. I completely agree with this. A script similar to metadata.xml - use.local.desc can be run on it (with more frequency), and eventually (EAPI=4?) we can move away from the file-based one. -- ~Nirbheek Chauhan GNOME Team, Gentoo
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote: Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill: On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? What I've really wanted for a long time is different package.mask files for different types of masks. eg. package.mask/broken.mask (qa.mask?) package.mask/removal.mask package.mask/security.mask package.mask/testing.mask To avoid collision with the current package.mask I'd prefer package.mask.d/ for the directory. Also makes the transition easy since we can generate package.mask out of the files in package.mask.d/. package.mask.d being directory and not used internally by PM - so being just a convention (which may be used for manually or scripted generation of resulting package.mask as dev-zero proposed- it's now utilized in kde-testing overlay because package.mask dir used to cause paludis crashes) can be implemented just now with no PMS changes (since PM is supposed to ignore unknown files/directories in there?). I'd suggest allowing package.mask as either directory or file though, no need for entities multiplying... besides the reference implementation in already there for ages. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thu, 13 Aug 2009 17:32:56 + (UTC) Mark Bateman coul...@soon.com wrote: It is not the business of PMS to enforce undocumented features that Portage supports only by accident and that aren't used in the tree. PMS doesn't depict just what portage should do, just what ebuild's in the main tree are to expect. PMS documents what ebuilds may or may not rely upon from the package manager. PMS, like the Portage document, says that package.mask is a file. This is a good feature (intentional or not) of portage and is already finding usage in overlays. And it shouldn't be until it's gone through the proper process to become a documented, controlled feature rather than an accident people are exploiting. Seriously, this isn't difficult to do. I get the impression people are only trying to avoid doing it properly here so they can establish a precedent of not doing things properly... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thu, 13 Aug 2009 18:06:04 + (UTC) Mark Bateman coul...@soon.com wrote: And it shouldn't be until it's gone through the proper process to become a documented, controlled feature rather than an accident people are exploiting. Seriously, this isn't difficult to do. I get the impression people are only trying to avoid doing it properly here so they can establish a precedent of not doing things properly... And if a developer would like to have it present in the main tree, sure push for an EAPI for it to be available in the main tree. Uh, yes, and that's what was being discussed before you jumped in and claimed that PMS should support it already. But as a feature that portage has that overlays can use it is useful. Not if those overlays want to claim any degree of PMS compliance. I'll remind you that not following PMS and instead relying upon flukes in Portage behaviour means your overlay can stop working at any moment and with no warning. It also means your overlay will only be usable with Portage, which won't sit very well with users of the dozen or more other tools that work with ebuilds and repositories. -- Ciaran McCreesh signature.asc Description: PGP signature
