Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/19/2010 10:49 PM, Andreas K. Huettel wrote: Wouldn't it also make sense to have per-category eclasses? This seems much more useful for me. Yes, probably. But it'll be enough getting per-package eclasses in, right now. I'll revisit this when we finally merge dev-php5 and dev-php. If other teams want to spin this - just go for it :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On Sun, 26 Sep 2010 15:07:33 +0200 Matti Bickel m...@gentoo.org wrote: On 09/19/2010 10:49 PM, Andreas K. Huettel Wouldn't it also make sense to have per-category eclasses? This seems much more useful for me. Yes, probably. But it'll be enough getting per-package eclasses in, right now. I'll revisit this when we finally merge dev-php5 and dev-php. If other teams want to spin this - just go for it :) Isn't the amount of work to get per-package eclasses basically the same as the amount of work to get per-(package and category) eclasses? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/26/2010 03:22 PM, Ciaran McCreesh wrote: Isn't the amount of work to get per-package eclasses basically the same as the amount of work to get per-(package and category) eclasses? Actually, I don't know. Tell me. I've no clue how much PM implementation effort this will be, yet. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On Sun, 26 Sep 2010 16:59:22 +0200 Matti Bickel m...@gentoo.org wrote: On 09/26/2010 03:22 PM, Ciaran McCreesh wrote: Isn't the amount of work to get per-package eclasses basically the same as the amount of work to get per-(package and category) eclasses? Actually, I don't know. Tell me. I've no clue how much PM implementation effort this will be, yet. The difficult bits are: * making sure you can do this without things going horribly wrong for older package managers * making sure metadata cache validation is right * checking everything that uses ECLASSDIR So from that, the complexity is in making eclasses not be in a single place, not in the number of places eclasses can be. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 9/20/10 7:30 PM, Alec Warner wrote: How does it provide more code sharing than the existing system? Previously I could put code I wanted shared: 1) In a global eclass, which means any ebuild in the tree can likely use it A global eclass is quite heavyweight. It requires a review on gentoo-dev, is difficult to deprecate, and so on. That's discouraging if you only want to share 2-3 simple functions used by only one package. 2) In a pkg eblit Which is hacky. Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? No. It lowers the barrier to entry in cases where the shared code is only useful for one package. It can always be promoted to a global eclass later (with a proven API). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 9/19/10 9:14 PM, Matti Bickel wrote: So, yeah, what do you think? Is it worth it? I second this GLEP. It seems like it will cleanly replace our hacked eblits implementations from packages like php, glibc, and possibly more. Also, it will allow more code sharing between ebuilds, which is good. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On Mon, Sep 20, 2010 at 5:19 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 9/19/10 9:14 PM, Matti Bickel wrote: So, yeah, what do you think? Is it worth it? I second this GLEP. It seems like it will cleanly replace our hacked eblits implementations from packages like php, glibc, and possibly more. Also, it will allow more code sharing between ebuilds, which is good. How does it provide more code sharing than the existing system? Previously I could put code I wanted shared: 1) In a global eclass, which means any ebuild in the tree can likely use it 2) In a pkg eblit Under the new system I can put the code: 1) In a global eclass, any ebuild can likely use it 2) In a per-package eclass, only one package can use it 3) In a pkg eblit, only one package can use it Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? -A Paweł
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/20/2010 07:30 PM, Alec Warner wrote: Under the new system I can put the code: 1) In a global eclass, any ebuild can likely use it 2) In a per-package eclass, only one package can use it 3) In a pkg eblit, only one package can use it Per package eclasses are pretty much eblits with some PM support thrown in. Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? No, code reuse will stay the same. What I like about the idea is moving more of the code closer to the ebuild files, tightening it's scope. No more wondering (as an ebuild author) if and how I could use php5_2-sapi.eclass - it just wouldn't be there. I'll answer more points tomorrow, but thanks for your ideas! signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: per package eclass GLEP
I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. GLEP: 62 Title: Per package eclasses Version: Last-Modified: Author: Matti Bickel m...@gentoo.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: Post-History: Abstract This document proposes a new kind of eclasses, which are specific to a certain package (hence per-package eclasses). It explains the current need for package specific eclasses, the proposed solution and a possible migration path. What is proposed is, in short, creation of eclasses in package directories for use by the ebuilds of the package in the same directory. Per-package eclasses can be thought of (broadly speaking) as normal eclasses used only by one package. Motivation and Rationale Gentoo currently provides 211 eclasses as of 14-08-2010, 36 of which are marked @DEAD and are scheduled for removal. At least three non-dead eclasses are specific to one package (mysql, php5_2-sapi and nvidia-drivers). The sheer number of eclasses makes it hard for old and new developers to quickly find the eclass they are looking for. Providing overlays and working on a single package also is not as easy as it should be. Last but not least, eclasses provided in the package directory could be part of the package's Manifest file, providing part of the eclass signing the Gentoo tree still lacks. Placing the package specific eclasses into the package directories themselves solves all of the problems mentioned (at least partly). It will reduce the clutter in the current eclass directory, provide a single directory to understand an ebuild and provides security benefits by including the eclasses in the Manifest file. Specification = The per-package eclasses are specified to be placed directly under the package directory (as described in [1]_). The eclass may have any name permissible for other eclasses (specifically, must end with .eclass). A per-package eclass is included in an ebuild by a new function ``pkg-inherit`` called in the global scope of the ebuild. The ``pkg-inherit`` function must be given zero or more arguments. If no argument is given, the function shall behave like it was called with the argument ``default``. It is specified to search the package directory of the calling ebuild (but no other directories) for eclasses with the names of the arguments and the suffix .eclass. If such files exist, they must be sourced by the function. If not specified otherwise below, the package manager shall treat the per-package eclass as a normal eclass in any other respect. It is made a requirement that per-package eclasses can not modify the ``EAPI`` variable. It is assumed ``EAPI``, if it set, is set before calling pkg-inherit. Backwards Compatibility === The current Package Manager Specification requires package managers to ignore anything in the top-level package directory that does not have a filename ending in .ebuild ([1]_). Thus package manager which do not implement the per-package eclass feature can ignore them. They, however, will fail to execute ebuilds making use of the new ``pkg-inherit`` function. It is therefore required this feature be made part of a new EAPI. Additionally, tools that regenerate the Manifest file should be aware of per-package eclasses. However, this is only of concern to developers regenerating Manifests in a specific package directory. It is assumed that whoever changes functionality in a package also uses tools capable of supporting features used in the package's ebuilds. Copyright = This document has been placed in the public domain. .. [1] http://distfiles.gentoo.org/distfiles/pms-3.pdf, Section 4.3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
Wouldn't it also make sense to have per-category eclasses? This seems much more useful for me. Examples where this would already make sense today: kde-meta, latex-package, ... Best, Andreas On Sunday 19 September 2010 21:14:56 Matti Bickel wrote: I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, sunrise dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: per package eclass GLEP
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel m...@gentoo.org wrote: I'm a couple weeks late with this, but here goes: from my failed attempts at reviving GLEP33 grow a discussion with ferringb on IRC about how to get what I wanted anyway :) I've placed my immediate feedback in CVS: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1r2=1.2 I will split the remaining commentary up into two sections: General Idea Feedback (call these non-editor related) and editorial feedback (generally segments you should add to the GLEP for editorial reasons.) We agreed that having eclasses specific to a package located someplace near the actual ebuilds was beneficial and should be supported by PMs somehow. Someplace and somehow are specified along some other details in the attached proposed GLEP. Feedback: I believe the biggest reason to have per-package eclasses is the following: 1) It limits how users can use an eclass. a) This makes mis-using eclasses harder to do; Interfaces that are hard to use incorrectly are good. b) It means changing an eclass affects fewer packages. It is currently difficult to control eclass consumers in the current model. (anyone can use any eclass.) c) It means eclass changes are easier to test. I think the GLEP attempts to over-blow the actual impact that its proposed changes may have. For instance I do not think per-package eclasses will drastically reduce the number of eclasses in the global eclass directory. It will not make overlays easier to use (possibly harder..actually.) Plus the number of eclasses that will move to per-package is likely few (the GLEP itself only notes three.) I'm posting this for review by the wider community, at the same time asking the GLEP editors (antarus? pva?) for guidance on the formalities. I gather the GLEP should get a number and be uploaded in CVS somewhere, as well as appear on the GLEP project page. Editorial: The proposal is vaguely similar to GLEP 33. There is also an existing implementation of per-package eclasses called eblits (used in glibc, possibly in other places.) The GLEP should refer to these (link to GLEP 33, if there is a page describing eblits; link to that as well.) The GLEP should also discuss why GLEP 33 and eblits are not the best implementation of this idea. If the GLEP makes claims such as 'The implementation will improve X or reduce Y by Z%' the GLEP should cite sources, data, or make some kind of argument as to why that is the case. For instance the GLEP refers to 'distributing ebuilds in overlays will be easier' but fails to discuss how it is easier in this new system. When thinking about these types of things; try to break them down into something measurable. For instance: With the old system there were 5 individual steps, the new system only has 3. The GLEP makes claims about how the per-package eclasses *could* be made part of the Manifest format. The GLEP should not focus on could. Either the per-package eclasses are part of the manifest code (per this GLEP) or they are not. If the GLEP dictates they are to be included in manifests the GLEP should discuss how exactly that will work (what types, checksums, etc..) If the eclasses are not required to be manifested then the GLEP should not tout that as an advantage over the status quo. So, yeah, what do you think? Is it worth it? Can the draft be improved? I'm specifically interested in the amount of work involved in supporting something like the thing laid out in the GLEP in our current PMs. Any dev can check stuff into other dev's individual CVS space. Feel free to edit the eclass in my devspace if you wish. I think there is some automation on the actual GLEP webspace now (that htmlifies GLEPS) so I am avoiding that space cause I forgot how exactly the automation works ;))
