Ciaran McCreesh wrote: > Please don't comment any further until you understand how this whole > thing works. >
I think this is a bit of an unrealistic expectation. This change impacts EVERYBODY - devs, users, etc. To expect people not to comment on it simply because they're not qualified to write a package manager is a bit naive. Like it or not you do need to obtain some kind of general agreement before making a change of this magnitude. Even so - I'm impressed about how civil this discussion has actually remained. Feel free to continue to make your points, but a GLEP requires some kind of census - not just silence after everybody gets tired of hitting reply. If somebody doesn't know what they're talking about - persuade them - don't just tell them to be quiet. I usually like to look at stuff like this in terms of pros and cons. So here are the pros and cons I can see regarding this change: PRO: Very simple to determine the EAPI of an ebuild - regardless of what is inside Works with existing PMs Simple CON: Yet another value to be parsed out of an increasingly-complex filename. Doesn't look pretty :) Makes a low-level detail more visible to users. You can't make a wild change to how EAPIs are specified - since old PMs will expect it to be in the filename in a particular format. The other option that seems popular is just continuing with EAPI=1 or whatever in the file (likely with a restriction on format that makes it parsable without BASH). I see these pros/cons for this solution: PRO: Very simple to determine the EAPI of an ebuild - regardless of what is inside Works with existing PMs Simple Doesn't add another field to the filename - reducing complexity Not very visible to users Looks pretty :) CON: You can't make a wild change to how EAPIs are specified - since old PMs will expect it to be inside the file in a particular format. I don't see how the latter is any worse than the former - its main limitation applies to both methods - just in a different place. I think you'd get far more consensus to the latter approach. And if for whatever reason this fails way down the road it could always be moved to the filename at that time.
smime.p7s
Description: S/MIME Cryptographic Signature
