Re: [gentoo-dev] GLEP 55 (why use filename extension?)
Peter Volkov wrote: > Well for me .ebuild-eapi is much more confusing. > > I still don't see why it's impossible to have eapi as a part of name but > not in extension... Although putting EAPI in the name and not the extension is *slightly* preferable to using the extension, I still do not think that it even belongs there for one main design-based reason: It does not have to be there from a design perspective. All other filename components (name-version-revision.ebuild) uniquely identify the ebuild. EAPI does not (it is meta-information only needed internally by the package manager or by someone interpretting the contents of the file). You could not have two ebuilds, for example, that have identical name/version/revision but different EAPIs - that would not make sense (and yet it would be possible if the EAPI were in the filename, causing the package manager to need rules for choosing the right ebuild to look at). The argument for putting the EAPI in the extension or filename is simply to address a particular technical implementation detail, and there are other, better, ways to solve the problem in my opinion. I would argue that GLEP 54 is also putting needless extra stuff in the filename, but we won't go there right now. :) -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
В Срд, 11/06/2008 в 08:34 +0100, Ciaran McCreesh пишет: > On Wed, 11 Jun 2008 11:25:50 +0400 > Peter Volkov <[EMAIL PROTECTED]> wrote: > > If you need eapi in file name what are the technical reasons of > > putting it into file name extension? Why don't you suggest better > > ebuild name like: > > > > pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? > > a) breaks current package managers That's why I suggested to change .ebuild extension or fix package manager now and wait another year to start using such syntax. Your answer about extension change > It means next time we want to introduce another backward incompatible > change, we have to go through the whole mess all over again. is not clear. What changes you have in mind? If we already have pkg, eapi and version in filename what else are you going to add there? > b) has no unambiguous parsing Why? For example, just add word eapi and that it: pkg-1.2.3-eapi-1.bld. That's just an example to show that this is possible. > c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a > lot like Debian-style foo-1.2-3 versions... Well for me .ebuild-eapi is much more confusing. I still don't see why it's impossible to have eapi as a part of name but not in extension... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
On Wed, 11 Jun 2008 11:25:50 +0400 Peter Volkov <[EMAIL PROTECTED]> wrote: > If you need eapi in file name what are the technical reasons of > putting it into file name extension? Why don't you suggest better > ebuild name like: > > pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? a) breaks current package managers b) has no unambiguous parsing c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot like Debian-style foo-1.2-3 versions... > I remember last time I've asked this genone told me that this is not > backward compatible. Ok, it's not, but what's the problem to change > extension once only for this change? It means next time we want to introduce another backward incompatible change, we have to go through the whole mess all over again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? I remember last time I've asked this genone told me that this is not backward compatible. Ok, it's not, but what's the problem to change extension once only for this change? Call you new files like pkg-ver-eapi.emerge and that's it! What is the need to change extension every time you introduce new eapi? Another possibility is to implement this new file format and wait another one year before using it instead of crapping the tree for years with such eapi-extesions... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
