Re: [gentoo-dev] Re: The fallacies of GLEP55
On Sunday 17 May 2009 06:43:50 Richard Freeman wrote: Duncan wrote: So I believe the cost to be quite reasonably managed, after all. Benchmarks would of course be needed to demonstrate that, but I believe it worth pursuing. I thought we had agreed that (1) with GLEP55 you have to source the ebuild anyway (whereas the other proposal allows to just parse it to get at the EAPI value) and (2) you can cache it sanely so that performance isn't the issue? Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but it seems like we're trying to squeeze every ounce of speed out of a non-indexed flat file database and do everything we can to avoid actually putting all that metadata in something that actually is queryable no matter how lousy the final design ends up being. The performance is really not an issue - the current design is quite limited and would need some interesting tweaks to go a lot faster. In terms of opening-and-looking-at files GLEP55 doesn't really offer a benefit, either you have a metadata cache which includes it (stat for existence of cache, stat for mtime of ebuild, open either ebuild or cache, source ebuild if cache is stale) or you have it in the filename (either the same sequence of operations if you cache it, or you source it because of the current restrictions in glep55) In other words, looking at performance in this case is just a distraction. Expressing the package database as a set of flat files works nicely - especially with cvs/git/etc. Actually working with that data directly on a real system doesn't make sense at all. Index it once and then only open the flat files on the rare occasion that you actually need to install one of them. Such an index can be centrally distributed, or it could be maintained as packages are rsynced (and of course users should be able to update it on demand as well). That sounds like a funny idea. I propose putting such a cache into /usr/portage/metadata/cache and have it contain pregenerated metadata keys, like DEPEND, HOMEPAGE and EAPI. When the speed of your package management system depends on the performance of find vs grep -r, you are doing something wrong. Neither works all that well. And when the difference is 0.03s out of 0.5s in the hot-cache and 4 seconds out of 75 in the cold-cache case you can't really optimize anything without considering more powerful options to increase performance ...
Re: [gentoo-dev] Re: The fallacies of GLEP55
Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh: On Sun, 17 May 2009 00:35:45 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: As for ciaranm's argument that you're restricting changes to the version string, say allowing -rc where _rc is now required, one-time restriction of a year or two, yes. However, if the spec is crafted such that the EAPI must be checked FIRST ...then the package manager has to inspect the metadata for every version of a package before it can do anything, rather than just starting at the best version and working downwards until it finds something usable, which is a pretty hefty price to pay. ... if the cache can be parsed at all. With GLEP-55 we might even choose to change the cache format. -- Tiziano Müller Gentoo Linux Developer, Council Member 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
Re: [gentoo-dev] The fallacies of GLEP55
Ben de Groot wrote: Patrick Lauer wrote: For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] The proposed solution to a problem that is never refined, This, in my opinion, is the crux of the matter. Most of us apparently are not sufficiently convinced that there actually is a problem. Until the problem is explained with clarity, the rest of the proposal is useless. Obviously you don't understand the issue, because if you did you'd support it! I concur that speaking for myself, I don't understand the issue. And it looks like many others don't either. So if anyone wants to promote this GLEP, their job is clear: make people understand what the issue is here, and convince them it is actually an issue. (Examples, scenarios usually work well, indeed a lot better than calling people names.) Is it really necessary to convince the entire community for every GLEP? I thought that the reason we have the council is so they can make decisions. You know specialization of decision making. If the council is going to expect anyone else, besides themselves, to understand an issue then why have the council. And maybe we can now spend the same amount of council-time (it has been eating time for over a year!) to get important things done ... I want to call on the Council to reject this GLEP in its current form, as the problem has been insufficiently clarified. We should not waste more time on it. I would like the Council to either accept, reject or send the GLEP back to be clarified if _THEY_ believe it has been insufficiently clarified to enable _THEM_ to understand the GLEP. Cheers,
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Am Donnerstag, den 14.05.2009, 20:48 +0200 schrieb Thomas Sachau: This is already done. darkside/idl0r did/do suggest sunrise to all maintainer-wanted bugs, that meet some specific criteria. noticed that, and i'd like to give a thanks guys for doing so :) But have to say, while hundreds of messages where sent, there is not much response from this until now. not much is not no response, maybe it would make it easier for users to get active with sunrise if we'd have a shiny x steps to commit to sunrise document maintained by our docs project (and also translated!). Plus from what i've seen on the overlays' sunrise wiki one who'd like to contribute needs to got to IRC to ask for an account - which most likely lots of possible contributors are not familiar with. Make it as easy as possible for those people! - oh and: promote it more actively. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] DESCRIPTION size
Hi, According to devmanunal [1], DESCRIPTION should be 80 characters max but according to repoman, DESCRIPTION should be 100 characters max. I'm confused, who should I believe ? :) [1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html Thanks, Mounir
[gentoo-dev] Re: DESCRIPTION size
Mounir Lamouri wrote: Hi, According to devmanunal [1], DESCRIPTION should be 80 characters max but according to repoman, DESCRIPTION should be 100 characters max. I'm confused, who should I believe ? :) [1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html Though I'm not a Gentoo dev, I'd say common sense dictates that the 80 characters limit is just a recommendation based on the 80x25 characters the default VGA text-mode supports. In other words, one line of text. In any event, I don't think any short description of any package would need more than that. But also don't think you would break any rules by using more than 80, unless it becomes clearly too long.
Re: [gentoo-dev] DESCRIPTION size
On Sun, 17 May 2009, Mounir Lamouri wrote: According to devmanunal [1], DESCRIPTION should be 80 characters max nitpicking It says less than 80 so 79 is the maximum. ;-) /nitpicking but according to repoman, DESCRIPTION should be 100 characters max. I'm confused, who should I believe ? :) [1] http://devmanual.gentoo.org/ebuild-writing/variables/index.html The devmanual also says Where possible, try to keep lines no wider than 80 positions. which would limit DESCRIPTION to 66 characters. These are guidelines, not strict rules. Keep it shorter if it's reasonably possible. Ulrich
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote: I thought we had agreed that (1) with GLEP55 you have to source the ebuild anyway (whereas the other proposal allows to just parse it to get at the EAPI value) and (2) you can cache it sanely so that performance isn't the issue? You don't /have/ to source the ebuild to get the EAPI for GLEP 55. That section is only there to cover corner cases that some people wanted to be well-defined, and it could easily be removed if the consensus is that that isn't a problem. On the other hand, it could equally well be added to whatever alternative solution you might suggest. Consider the case where you have a foo-1.2.ebuild-4, and in the contents of the file it sets EAPI=5. What should that mean? There are three possibilities that I can think of: 1) It's illegal, don't do that. Then there's no need to source the file to find the EAPI, because the corner case should never happen, and if it does, the behaviour can be left undefined. 2) It's legal, and the ebuild has EAPI 4. Then there's no need to source the file to find the EAPI, because the EAPI in the filename always wins. 3) It's legal, and the ebuild has EAPI 5. This requires sourcing the ebuild to find the EAPI, and it's what GLEP 55 currently says. Now consider the alternative fixed-format ^EAPI= suggestion. What if we have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 further down? What should that mean? The same three possibilities apply here as in the GLEP 55 case. If you think it should be illegal, or that it should mean EAPI=4, then there's no need to source the ebuild just to find the EAPI. If you think it should mean EAPI=5, then you do need to source the ebuild, exactly the same as in GLEP 55. Either way, this isn't a valid reason to choose the fixed-format alternative over GLEP 55, because the same concerns do or do not apply to both.
Re: [gentoo-dev] DESCRIPTION size
Ulrich Mueller wrote: The devmanual also says Where possible, try to keep lines no wider than 80 positions. which would limit DESCRIPTION to 66 characters. These are guidelines, not strict rules. Keep it shorter if it's reasonably possible. Even guidelines should be consistent. If devmanual recommand 80 and repoman 100, in my opinion, someone is wrong. repoman should recommand 80 or devmanual should recommand 100. That's surely not a major issue even far from that but having some consistency in those guidelines is a minimum. IMHO, repoman should be updated to 80. Mounir
Re: [gentoo-dev] The fallacies of GLEP55
On Sun, May 17, 2009 at 12:35:43AM -0400, Richard Freeman wrote: Ravi Pinjala wrote: Nick Fortino wrote: Such a transformation is possible, given the restrictions on arg, as well as ebuild format. Isn't this a bit circular? The whole point of wanting to change the extension is to get rid of exactly these restrictions; if you assume the restrictions, then the whole thing is kind of pointless. :) What restrictions? The restriction that EAPI be fixed on the 5th line of the build, or the restriction that EAPI be fixed in the filename. I don't really see much difference between them. What can the one do that the other can't. The difference is that putting the EAPI in the filename has backwards compatibility because package managers not knowing about this change won't even look at the those ebuilds. Putting EAPI as the fifth line completely loses this, so as far as backwards compatibility goes putting EAPI 55 in the filename really is the cleanest. -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpTTGoJ1MWDK.pgp Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Sun, 2009-05-17 at 07:40 -0400, Thomas Anderson wrote: [...] The difference is that putting the EAPI in the filename has backwards compatibility because package managers not knowing about this change won't even look at the those ebuilds. Putting EAPI as the fifth line completely loses this, so as far as backwards compatibility goes putting EAPI 55 in the filename really is the cleanest. That's not very hard to overcome without polluting the file name, as I've already pointed out. -- Arun signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] DESCRIPTION size
Mounir Lamouri wrote: Ulrich Mueller wrote: The devmanual also says Where possible, try to keep lines no wider than 80 positions. which would limit DESCRIPTION to 66 characters. These are guidelines, not strict rules. Keep it shorter if it's reasonably possible. Even guidelines should be consistent. If devmanual recommand 80 and repoman 100, in my opinion, someone is wrong. repoman should recommand 80 or devmanual should recommand 100. That's surely not a major issue even far from that but having some consistency in those guidelines is a minimum. IMHO, repoman should be updated to 80. Mounir When I made the repoman check putting 80 there got opposition. I am not entirely sure but I think zmedico and vapier wanted to put 100 there although we do recommend keeping it under 80. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Files owned by multiple slots
Sven wrote: Gilles Dartiguelongue eva at gentoo.org writes: so this wrapper could be installed in a separate eselect sort of package ? How exactly can this be done? If a gem creates five executables, would this mean that this gem comes in six ebuilds? well given the next answer, it sounds like that's what I'm proposing. I release this might create a packaging overhead. I'll check the docs to learn about how this could be done. Yet meanwhile I'd love to get some feedback on my original proposition: Is it feasable and acceptable to expand Portage by the possibility to declare a file shared between slots and only delete it once the last slot is uninstalled? Thanks for some feedback on this! -sven This can also be accomplish by a shared dependency package so is there a particular benefit for extending EAPI to support this? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The fallacies of GLEP55
Alistair Bush wrote: Is it really necessary to convince the entire community for every GLEP? I thought that the reason we have the council is so they can make decisions. You know specialization of decision making. If the council is going to expect anyone else, besides themselves, to understand an issue then why have the council. They are a representative body. OF COURSE they should care what the community thinks. They weren't elected SOLELY for technical ability. Sure, they should use their own judgment as well. However, GLEPs should certainly be debated by the community before they are adopted, and the opinions expressed on-list should certainly be taken into account. Now, does that mean that every decision requires unanimous community agreement? Of course not! However, the vigorous debate that GLEP55 seems to inspire suggests that there are more than just a few hold-outs.
Re: [gentoo-dev] EAPI Changes
Ciaran McCreesh wrote: On Sat, 16 May 2009 02:31:45 +0300 Petteri Räty betelge...@gentoo.org wrote: On the other hand you also have to make sure you have a stable portage for a time long enough so mostly everyone has it installed. Otherwise you could break users systems pretty badly depending on the packages. And Arch-Teams usually do a pretty good job in catching such cases. How would this breakage happen? The ebuild in the vdb still has the old EAPI. Portage likes to use metadata from the tree version of things even if there's also a version installed. This is a major nuisance, but is unfortunately considered a feature. I think the question here is that what Portage does when there's a newer EAPI in the tree version that Portage does not yet support but there's a supported version in the vdb. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] GLEP 55 updated
Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. Imho, council should first vote on whether they see the problem described in the GLEP as real (do we all agree on that at least?) and then pick one of these solutions. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. [1] - http://dev.gentoo.org/~peper/glep-0055.html (http://www.gentoo.org/proj/en/glep/glep-0055.html once it synces) -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! /loki_val
[gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Piotr Jaroszyński pe...@gentoo.org: I have just updated GLEP 55 [1], hopefully making it a bit clearer. Thanks a lot Piotr. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change My preference goes to 3 with a .eb extension and EAPI on the first line. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. We need all the problem solving people we can get. And since we're all volunteers there's no way we can force anybody to do anything. So, sure, there may be a need for prioritizing problems, but one problem solved is one less on the pile whatever it was. Denis.
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Sun, 17 May 2009 04:07:18 + (UTC) Mark Bateman coul...@soon.com wrote: On Sat, 16 May 2009 21:58:10 + (UTC) Mark Bateman couldbe at soon.com wrote: The current way of specifying the EAPI in ebuilds is flawed That is not defining the problem, that is an opening statement. That is the problem. No, that is a summary of the problem. Not once has the actual problem been described or documented. ...except where it's described right at the start of the GLEP, under the 'Problem' section. Until such information is provided continued discussion of this GLEP is not going to progress since words like *obviously* are substituted for actual facts, a substitution which does not provide anything new to this discussion You are expected to have a basic understanding of the material under discussion before joining in. Although it might be nice to live in magic fairy land where everyone has time to explain every single issue at a level sufficient for a three year old who does not speak English to be able to understand it, in reality we have to expect you to understand the basics before getting involved. However, this is not the only method to determine the EAPI of an ebuild that exists and as such the viability of GLEP55 as the best solution is brought into question Yes, it is the only method. No it is the only method you are willing to accept, there is a big difference. Many people have mentioned in passing other means of determining the EAPI of an ebuild pre-sourcing (thus allowing the PM to source the correct eclass or flag up warnings...) YET they have just been shot down with no actual technical reason, except they do not involve coding the EAPI into the filename. Uhm. Please go back and re-read both the GLEP and the threads. Claiming no actual technical reason when actual technical reasons have been provided is not helping anyone. Where is it defined that the ebuild must be sourced 1st? Why does the ebuild have to be sourced 1st? Such things are obviously true to anyone with a basic understanding of the domain. So you are unable to actually reference any credible source of information to back up your claims then. Uhm. No. Go and look at how any of the package managers work. Go and read PMS. Notice how, by the very definition of EAPI, the only way you can get EAPI at present is to source the ebuild. Please make sure you're familiar with the basics of how metadata works before commenting any further. What has my understanding or lack of understanding of metadata have to do with my statement that other means exist to determine the EAPI of an ebuild before sourcing said ebuild? This is meant to be a discussion about The fallacies of GLEP55 Uhm. EAPI is, at present, a metadata variable. If you don't even know that, what on earth are you doing talking in this thread? Please stop wasting everyone's time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change, and we can't make global scope changes to EAPIs using current mechanisms. EAPIs have to carry on using bash 3 until the EAPI mechanism is changed. Second, by order of the Council, EAPI 3's feature list was locked several weeks ago. If we ignore that for one thing, it just means everyone else who had features that came along too late will start demanding we reconsider those too... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. This is glep 55 material. I will update it to reflect that. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Sunday 17 May 2009 18:35:29 Ciaran McCreesh wrote: Please stop wasting everyone's time. Yes, please do. Your replies are full of emotional arguments and ad hominem attacks. If you are unable to keep to the technical aspects of a discussion you should reconsider answering to every email (which is also extremely tiresome by volume alone). Now if we can please keep this a discussion (which means tolerating other peoples opinions) we might be able to reach some results. That also means that we do not know a priori how to solve the problem and that there may be more than one solution, kay?
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? and we can't make global scope changes to EAPIs using current mechanisms. EAPIs have to carry on using bash 3 until the EAPI mechanism is changed. IMHO ebuilds are allowed to set DEPEND==app-shells/bash-4.0 and use bash-4.0 features anyway, but it would be easier to just set appropriate EAPI in ebuilds. Second, by order of the Council, EAPI 3's feature list was locked several weeks ago. If we ignore that for one thing, it just means everyone else who had features that came along too late will start demanding we reconsider those too... IMHO addition of this feature would be acceptable. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? I have updated the glep, see how it breaks [1]. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sun, 17 May 2009 18:58:58 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? Package managers still need to be able to get the EAPI, even if they don't support newer EAPIs, which means you're restricted to using syntax that bash-3 can parse. Although you can sneak some bash-4 features through bash-3's parser, it gets extremely confusing. and we can't make global scope changes to EAPIs using current mechanisms. EAPIs have to carry on using bash 3 until the EAPI mechanism is changed. IMHO ebuilds are allowed to set DEPEND==app-shells/bash-4.0 and use bash-4.0 features anyway, but it would be easier to just set appropriate EAPI in ebuilds. Er, no. An ebuild's deps aren't met when the package manager generates metadata from the ebuild. Second, by order of the Council, EAPI 3's feature list was locked several weeks ago. If we ignore that for one thing, it just means everyone else who had features that came along too late will start demanding we reconsider those too... IMHO addition of this feature would be acceptable. You could say that about any feature, but the Council chose to just go with an absolute cutoff. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
On Fri, 15 May 2009 23:31:25 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Wrong. For example: - stuff like docompress may change the content being installed depending on the package manager - --disable-static (maybe in a later EAPI) changes content - slot-dep-operators change the rdepend of installed packages, so it changes how the package manager has to handle reverse packages on uninstall (in EAPI 3) None of which are a problem when changing the EAPI from 0 to 1, which is the situation here. The first two examples fall under the currently established guideline of revbumping when content changes (and I emphasize guideline). I don't see how the third example is any different than adding or removing dependencies, which also does not require a revbump. So I'd argue that an EAPI change does not require a revision bump in and of itself. That's not to say it shouldn't be done if the situation allows, or you have any doubts, or just because you want to. But unconditionally putting an ebuild through full ~arch to stable cycle because you added a simple SLOT dependency or a + to a USE flag is bureaucratic nonsense. And we also always said that a rev bump should be done on non trivial changes or non-build-fixes and changing the EAPI is technical seen mostly a non-trivial change. As above, it depends on the situation. 0 - 1 is a trivial change. Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) As soon as a version of portage supporting that EAPI is available. This is the entire point of the EAPI, that we don't have to wait X amount of time before using new features. If the user hasn't updated portage yet, they simply won't see ebuilds which use the new EAPI. We may want to document a suggested waiting time before removing ebuilds using older EAPI's. For example, should we always keep an EAPI 0 ebuild in stable as a fallback? Or if the user tries to install or update a package where all versions are masked by EAPI, should (does?) portage suggest updating itself? How long should we keep core system packages at earlier EAPI's? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. Ulrich [1] http://filext.com/file-extension/EB
Re: [gentoo-dev] license issue with fretsonfire
Arun Raghavan wrote: On Sat, 2009-05-02 at 18:17 +0200, Mounir Lamouri wrote: [...] I think the code can be considered GPL-2 (i will check if there is no header specifying something else) and for the fonts, I will have to add 2 licenses not in the tree at the moment. But what to do with the songs ? I suppose it's not the first GPL game having non very clear license about data. How games team is managing that ? The fonts license seems to be the same as licenses/BitstreamVera which is in-tree. As for the songs, does it make sense to put that in a separate package that the code package depends on? The package can have the restrictive license it is distributed under and RESTRICT=mirror bindist. -- Arun I've contacted upstream and I sent me the Debian bug [1] about fretsonfire. They suffered from similar issues. To solve fonts issue, I think we can fix that like Debian: using other fonts. We can even using the same ones. To solve the songs issue, I see two solutions: 1. removing songs from the tarball (should we do/mirror a new tarball ?) and adding packages with free songs (Debian's solution) 2. using RESTRICT=mirror bindist as Arun proposed (btw, is bindist really for binary because it's in python so there is no binary) I don't know if we can solve the song issue with a separated package. Because this songs are following the Toesto (Finish organization to protect artists work iirc) rules they must be bundled with the game. We probably should do the same. Or maybe RESTRICT=fetch can solve this ? I think the real issue with the songs is there is no real license linked with it except you can't do anything with them except listening to. I think even with the most restrictive parameters, we can't deal with that. Am I right ? I think the most secure way for Gentoo is to do as Debian is doing. May be even using Debian's package. I would appreciate some help/advice here as I'm not a lawyer :) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383316 Thanks, Mounir
Re: [gentoo-dev] GLEP 55 updated
On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen loki_...@gentoo.org wrote: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! I sincerely hope that was sarcasm. -- ~Nirbheek Chauhan
Re: [gentoo-dev] GLEP 55 updated
Denis Dupeyron wrote: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change My preference goes to 3 with a .eb extension and EAPI on the first line. I second this. :) Although I do not have a strong preference of in-file position, first line makes it like a she-bang, and that sounds good all around. -Joe
Re: [gentoo-dev] GLEP 55 updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. I also prefer 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. Ulrich [1] http://filext.com/file-extension/EB - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoQS84ACgkQcAWygvVEyAJ2gwCfUXuvc1f995QTxkElrPlY9I1H R6oAn0CMpXBe4Y8qnbkCleS3CgNbHJcK =kwqB -END PGP SIGNATURE-
Re: [gentoo-dev] GLEP 55 updated
On Sunday 17 May 2009 20:39:26 Jorge Manuel B. S. Vicetto wrote: Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. I also prefer 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Yeah, this sounds pretty reasonable to me :) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
Jorge Manuel B. S. Vicetto wrote: As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Well, if a she-bang, should be the first line. That also makes parsing a lot more straightforward and easily defined. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. I'd hate to see the length grow - shrinking is better and cleaner. :) .gebuild is a little unwieldy IMHO. Also, since ebuilds can be used with distros other than gentoo itself, having the g there may not be a good idea. -Joe
[gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On Thu, 14 May 2009 03:32:12 +0300 Mart Raudsepp l...@gentoo.org wrote: Project maintainer-wanted = Abstract: There are currently quite some package requests (over 3000) languishing on bugzilla waiting for a developer or team to get interested and package it in the official gentoo-x86 portage tree. However in quite some cases that might not happen for quite a while even with very popular packages desired by users. The purpose of the maintainer-wanted project is to get as many of such packages to the official tree as possible as a stopgap solution. Actually, I'm working on a get the crap out of the tree project that is pretty much the exact opposite of this. ;) But, things I like: - metrics for package popularity (can we do gentoo-stats already?) - encouraging teams and maintainers to take an interest in unmaintained packages - keeping track of maintainer-wanted/needed packages through categorization, etc. - proxy-maintainers These things I think would benefit both projects, as well as several others. I would actually rather see our overall package count dropping than growing, but if we're adding quality, maintained stuff and tossing out the garbage then I guess that's an improvement too. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/17 Ryan Hill dirtye...@gentoo.org: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. That's covered in the GLEP: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing authors to provide backwards compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect on a given system. I don't see a way to overcome these problems in a sensible way. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 12:15:24 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. We couldn't. Allowing multiple equal but different ebuilds gets highly crazy -- EAPIs aren't orderable, so it's not obvious which one the package manager should select. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
Hi, On 2009/05/17, Piotr Jaroszyński pe...@gentoo.org wrote: I have just updated GLEP 55 [1], hopefully making it a bit clearer. In the GLEP, you raises the following argument against the Easily fetchable EAPI inside the ebuild class of solutions: Performance decrease comes from the fact that with version format changes in the picture package managers need EAPI to parse the ebuild's version. That means that merely picking the best version of a package requires loading EAPI (from cache or the ebuild) for each available ebuild. This argument is wrong imho. Future EAPIs can't be allowed to introduce backward-incompatible changes to the versions ordering rules, or they would make the PM behavior ill defined. Or, more precisely, if a PM adopts an EAPI with such a change, it has to drop support for the older incompatible ones. Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? So, basically, we are, and will stay, in a situation such that there is a complete order relation beetween all the version strings supported by at least one of the EAPIs implemented by the PM, and all the versionning rules of this EAPIs match this order relation. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string 2- among the remaining ones, parse and sort versions (sure, would actually be done together with step 1, for performances reasons) 3- get metadatas for the best one (generate or pick in cache), and check its EAPI that it is a supported one, and also that the version string is allowed in this EAPI 4- loop on step 3 if EAPI check failed It is as fast as the algorithm GLEP55 promotes, but in the case you're using an old package manager and there is really a lot of ebuild updates you skip because of unsupported EAPI (here you still fetch their metadata, but not with GLEP55). But i don't see it as a nominal case. Thanks, -- TGL.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 20:40:37 +0200 Thomas de Grenier de Latour tom...@free.fr wrote: This argument is wrong imho. Future EAPIs can't be allowed to introduce backward-incompatible changes to the versions ordering rules, or they would make the PM behavior ill defined. Or, more precisely, if a PM adopts an EAPI with such a change, it has to drop support for the older incompatible ones. Not exactly true. It means that EAPI version rules have to be mappable onto a single larger superversion format in such a way that they have a total order. Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. Although that's a fairly convoluted example, and not in line with what's being proposed for future EAPIs. What we're after is the ability to allow versions like 1.2.3-rc1. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 22:54:38 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen loki_...@gentoo.org wrote: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! I sincerely hope that was sarcasm. I don't want us to get to a place where every single new feature has to be delayed by the objection We've got basic bugs we need to fix first. That's just unreasonable and a straw man. I get my kicks from improving things, not from fixing broken things. You may object and say they're one and the same, and you would not be wrong, but the emphasis *is* different. People seem to not see that in the case of GLEP 55 and some call for a moratorium on new features till we've fixed the bugs that already exist. Not gonna happen. The human spirit is what's driving Gentoo, giving it life. Our aspirations to improve the world around us lives and breathes with every ebuild we churn out. World domination is our goal and we won't get there by letting the maintainer-needed queue bog us down. I think that it's obvious to everybody that the problem GLEP 55 is solving is real. To me, .ebuild-$eapi/.eapi-$eapi.eb looks like the best solution, all things considered. From a purely unixy point-of-view, I see the cleanliness of a shebang EAPI definition, and that would be my second choice, but we need a solution we can use now. Not a year from now. Time really does matter. My dislike for the GLEP 55 process is my main reason for supporting GLEP 55 as-is. If we can skip just one more 50-mail thread because of GLEP55, it will be worth the extra work of typing -$eapi every now and then. Because seriously, if ever there was a mailing list topic whose only effect has been to act like a succubus, GLEP 55 is it. ( In other words: No sarcasm intended ) /loki_val
Re: [gentoo-dev] GLEP 55 updated
On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild From what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that introduces changes as described in the Current behaviour section. (4) would otherwise keep the current workflow the same except restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that do not carry a metadata cache (overlays) which use new EAPIs also keep their portage version current. I'd say go with option (4) now and by the time EAPI 4 is collected, written up, agreed upon and implemented, enough time went by so we would not have to introduce an artificial delay. And after that, there won't be any delay to avoid breakage anymore. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: information on localstatedir
William Hubbs willi...@gentoo.org said: I was told by the brltty developers that localstatedir should be /var. I noticed, however, that econf passes --localstatedir=/var/lib to the configure script. The way around this was to pass the --localstatedir option to econf. According to FHS we are doing it right: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION I guess what I would really like to know is...why does it matter? If something is configurable like that, then it should work regardless of what is put in. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpDmYeIX5LuK.pgp Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 19:18:14 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 17 May 2009 12:15:24 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. We couldn't. Allowing multiple equal but different ebuilds gets highly crazy -- EAPIs aren't orderable, so it's not obvious which one the package manager should select. Ah, right. I knew there was a reason. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI Changes
Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill: On Fri, 15 May 2009 23:31:25 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Wrong. For example: - stuff like docompress may change the content being installed depending on the package manager - --disable-static (maybe in a later EAPI) changes content - slot-dep-operators change the rdepend of installed packages, so it changes how the package manager has to handle reverse packages on uninstall (in EAPI 3) None of which are a problem when changing the EAPI from 0 to 1, which is the situation here. The first two examples fall under the currently established guideline of revbumping when content changes (and I emphasize guideline). I don't see how the third example is any different than adding or removing dependencies, which also does not require a revbump. Which is mostly wrong as well since a change in dependency means that the currently installed stuff may break if a package (the new dependency for example) gets removed and since the package you changed does not reference it, it gets broken (for example if you had a magic dep before and add it now as an explicit dep). So, unless you're doing a pkgmove it's a dangerous thing since the PM can't reliably track reverse deps when doing uninstalls since it has to use the vdb entry for that, doesn't it? So I'd argue that an EAPI change does not require a revision bump in and of itself. EAPI may imply a decent implicit change to the ebuild and therefore needs a rev-bump as per the manual. That's not to say it shouldn't be done if the situation allows, or you have any doubts, or just because you want to. But unconditionally putting an ebuild through full ~arch to stable cycle because you added a simple SLOT dependency or a + to a USE flag is bureaucratic nonsense. And we also always said that a rev bump should be done on non trivial changes or non-build-fixes and changing the EAPI is technical seen mostly a non-trivial change. As above, it depends on the situation. 0 - 1 is a trivial change. Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) As soon as a version of portage supporting that EAPI is available. And how much time a portage with a new EAPI got stabled? (see for example early python eapi bumps) This is the entire point of the EAPI, that we don't have to wait X amount of time before using new features. If the user hasn't updated portage yet, they simply won't see ebuilds which use the new EAPI. We may want to document a suggested waiting time before removing ebuilds using older EAPI's. For example, should we always keep an EAPI 0 ebuild in stable as a fallback? Or if the user tries to install or update a package where all versions are masked by EAPI, should (does?) portage suggest updating itself? It would maybe suggest to update to an unstable version of portage, not so good then? -- Tiziano Müller Gentoo Linux Developer, Council Member 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
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
Arfrever Frehtes Taifersar Arahesis wrote: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? Because he wants to push GLEP 55. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
[gentoo-dev] Re: scm in GLEP 54 (was: Council meeting summary for meeting on May 14, 2009)
Thomas Anderson wrote: - Vote on GLEP 54 This vote was called for by dertobi123. The vote was on whether to approve GLEP 54 conditional on whether GLEP 55 is passed. The reason for this is that GLEP 54 is unimplementable without the problems mentioned in GLEP 55 being solved. I have not seen much discussion lately regarding the choice of the string, scm in this GLEP. I asked the author today on IRC, and he said he doesn't have a particularly strong reason for scm beyond historical reasons. Since we are stuck with the string once it is adopted, I think we should consider the choice carefully. Personally, I'd prefer live, since it is what we've been calling these ebuilds for a long time, it's easier to remember (and more catchy), and it seems to carry the spirit of what we mean by these kinds of ebuilds. Also, there is a new in-ebuild property with the signifier live. Comments? -Joe
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sun, 17 May 2009 21:22:57 +0200 Ben de Groot yng...@gentoo.org wrote: Why do you think that it is a global scope change? Because he wants to push GLEP 55. Ben, please stop that and apologise for your behaviour. It's already been explained why changing bash versions is a global scope change, so you've got no excuse for posting such nonsense. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
Just a heads up that I wrote a more detailed description of the peformance hit that EAPI in the ebuild introduces. Might come up with some numbers later too. [1] - http://dev.gentoo.org/~peper/glep-0055.html#easily-fetchable-eapi-inside-the-ebuild -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009/5/17 Ben de Groot yng...@gentoo.org: Arfrever Frehtes Taifersar Arahesis wrote: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? Because he wants to push GLEP 55. Would you care to look at [1] and see how it breaks first before posting BS like that? Better yet test it youtself. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 55 updated
2009-05-17 20:57:25 Robert Buchholz napisał(a): On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild +1 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: scm in GLEP 54 (was: Council meeting summary for meeting on May 14, 2009)
On Sun, 17 May 2009 13:24:27 -0600 Joe Peterson lava...@gentoo.org wrote: Thomas Anderson wrote: - Vote on GLEP 54 This vote was called for by dertobi123. The vote was on whether to approve GLEP 54 conditional on whether GLEP 55 is passed. The reason for this is that GLEP 54 is unimplementable without the problems mentioned in GLEP 55 being solved. I have not seen much discussion lately regarding the choice of the string, scm in this GLEP. I asked the author today on IRC, and he said he doesn't have a particularly strong reason for scm beyond historical reasons. About a million years ago, we were going to move all the SCM packages into their own category (but it never happened, because port001's script didn't work). There was a huge bikeshed debate about whether to use vcs, rcs, scm or something else. In the interests of getting anything decided, Seemant made an executive decision and picked 'scm'. History suggests that if it goes up for debate again, no decision will ever be reached. Thus, the only sensible thing to do is to let the old decision stand. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Robert Buchholz r...@gentoo.org: On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? I would like to avoid user-visible breakage as much as possible. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Yet another proposal for ebuild extensions
Ravi Pinjala wrote: Instead of changing rules for existing ebuilds, then, why not formalize some guidelines for non-ebuild-compatible packages in the tree, separate from EAPIs? Allowing new package formats is the next logical generalization after considering new and incompatible ebuild formats, and it would probably be cleaner overall, while giving people the freedom to experiment with whatever wild ideas they have for packages. Ebuilds work well enough for us. I don't think there's a real need for other formats. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] rfc: information on localstatedir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 17, 2009 at 02:57:47PM -0400, Mark Loeser wrote: According to FHS we are doing it right: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION I guess what I would really like to know is...why does it matter? If something is configurable like that, then it should work regardless of what is put in. I guess it doesn't matter to me really; I was just looking for why we do it the way we do since one of the brltty devs strongly recommended that we change our build environment. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoQa8sACgkQblQW9DDEZThSygCeNBeribtJLB5MRx4QMeoElU9k vzoAn2I3JG/bvcSMoWb4KRu7W9XDmOD4 =oHRJ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: scm in GLEP 54 (was: Council meeting summary for meeting on May 14, 2009)
On Sun, 17 May 2009, Ciaran McCreesh wrote: History suggests that if it goes up for debate again, no decision will ever be reached. If we simply have to decide between alternatives scm and live, then I don't see what should be so complicated about reaching a decision. GLEP 54 doesn't really make clear the connection between the suffix and source code management is. It mentions source code management only shortly in the abstract, and then discusses things like version ordering that are not related to it. And does it really matter if the ebuild obtains its sources via a SCM system, or by some other means? Seems to me that live describes the property better. Ulrich
Re: [gentoo-dev] GLEP 55 updated
On 2009/05/17, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take =bar/foo-1_p as an emerge command line argument for instance, is my foo-1_p1.ebuild a candidate? Although that's a fairly convoluted example, and not in line with what's being proposed for future EAPIs. What we're after is the ability to allow versions like 1.2.3-rc1. Right, and for this kind of reasonable future needs, it's easy enough to ensure enough backward compatibility so that we don't need to add the EAPI each time we talk about a version. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the best correct one. Which is well enough. -- TGL.
Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
Piotr Jaroszyński wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: Arfrever Frehtes Taifersar Arahesis wrote: 2009-05-17 18:37:32 Ciaran McCreesh napisał(a): On Sun, 17 May 2009 18:20:21 +0200 Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote: I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). No good, for two reasons. First, this is a global scope change Why do you think that it is a global scope change? Because he wants to push GLEP 55. Would you care to look at [1] and see how it breaks first before posting BS like that? Better yet test it youtself. [1] - http://dev.gentoo.org/~peper/glep-0055.html#use-newer-bash-features Okay, after reading the updated GLEP, I see what you mean. Let's continue to discuss this in the GLEP 55 updated thread, and I promise to be more constructive. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] Re: scm in GLEP 54
Joe Peterson wrote: I have not seen much discussion lately regarding the choice of the string, scm in this GLEP. I asked the author today on IRC, and he said he doesn't have a particularly strong reason for scm beyond historical reasons. Since we are stuck with the string once it is adopted, I think we should consider the choice carefully. Personally, I'd prefer live, since it is what we've been calling these ebuilds for a long time, it's easier to remember (and more catchy), and it seems to carry the spirit of what we mean by these kinds of ebuilds. Also, there is a new in-ebuild property with the signifier live. Personally I think there is humor in the scum (as I pronounce it). But seriously, I think live makes sense, and would likely be clearer to our users as well. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] Re: scm in GLEP 54 (was: Council meeting summary for meeting on May 14, 2009)
On Sun, 17 May 2009, Ciaran McCreesh wrote:
About a million years ago, we were going to move all the SCM
packages into their own category (but it never happened, because
port001's script didn't work). There was a huge bikeshed debate
about whether to use vcs, rcs, scm or something else. In the
interests of getting anything decided, Seemant made an executive
decision and picked 'scm'.
And please don't mix completely unrelated topics. The discussion at
the time [1] was about moving dev-util/{cvs,git,subversion} etc. to
a new category, and clearly dev-live would not be a good choice
for that.
Ulrich
[1]
http://archives.gentoo.org/gentoo-dev/msg_d05c27cf1cce095b3e18b0a9765137c5.xml
[gentoo-dev] GLEP54 vs. package.mask (was: Council meeting summary for meeting on May 14, 2009)
On 2009/05/17, Thomas Anderson gentoofa...@gentoo.org wrote: - Vote on GLEP 54 This vote was called for by dertobi123. The vote was on whether to approve GLEP 54 conditional on whether GLEP 55 is passed. The reason for this is that GLEP 54 is unimplementable without the problems mentioned in GLEP 55 being solved. Conclusion: Conditionally approved on whether GLEP 55 is approved. Sorry if the question has already been raised (i would be surprised it was not), but... Back in january [1], it was decided that base profile (and thus package.mask) should stay in EAPI=0 syntax. So once you've approved GLEP55 (or an alternative) and introduced an EAPI with support for -scm suffix, how will you package.mask this new-style live ebuilds? There is some elusive answer in the GLEP itself [2], but i don't understand it: either it's correct but then i wonder why wait for GLEP55, or it's not and then there is more than just GLEP55 which is needed before allowing this kind of version syntax extension. Thanks for the explanation. [1] the question at this time was whether slot deps where usable there: http://thread.gmane.org/gmane.linux.gentoo.devel/59458 [2]http://www.gentoo.org/proj/en/glep/glep-0054.html#backwards-compatibility -- TGL.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 21:57:40 +0200 Thomas de Grenier de Latour tom...@free.fr wrote: On 2009/05/17, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take =bar/foo-1_p as an emerge command line argument for instance, is my foo-1_p1.ebuild a candidate? Conceptually, you'd define a 'user' EAPI for those things, so you can define it any way you want (including in such a way that the _p thing works both ways depending upon the EAPI used for creating the thing you're comparing it to -- for the user EAPI, you'd define it as being _pUNSPECIFIED rather than _p0 or _pINFINITY and use the other side of the comparison to decide the result). But yes, if you do something silly like your example, things get very complicated. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the best correct one. Your previously stated restrictions are too strong, though. And when it turns out a future change breaks those restrictions, we'd be back to yet another extension change. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
Ryan Hill dirtye...@gentoo.org posted 2009051752.133c7...@halo.dirtyepic.sk.ca, excerpted below, on Sun, 17 May 2009 11:11:52 -0600: Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) As soon as a version of portage supporting that EAPI is available. That's a dangerous position to take. See experimental EAPIs for instance, sometimes temporarily supported by portage, but NOT for use in the tree. But I think you knew that and simply made some assumptions with the statement that not all readers may have. This is the entire point of the EAPI, that we don't have to wait X amount of time before using new features. If the user hasn't updated portage yet, they simply won't see ebuilds which use the new EAPI. Agreed. As I've seen it stated, an EAPI must be approved by council before ebuilds using it are allowed in-tree at all. Procedure there seems to be that final approval does not occur until all three PMs support it. (See EAPI-3, now preapproved, but conditional on feature implementation, with removal of some feature or other possible before final approval if not all PMs support it in a timely manner.) That's for in-tree. For arch-stable, the qualifier is no longer all three PMs, but only portage, as the default PM at this time. When a portage version supporting the approved EAPI is stable, ebuilds using it may be stabilized as well. But I agree that the point of EAPIs is to avoid delay, and that once an EAPI has final approval (as I said, itself conditional on working implementation in ~ versions of the PMs), there's no need to wait longer to put it in-tree as masked or unstable. And for stable, once a portage with the approved EAPI goes stable, so can packages using it. That's my understanding of council and QA policy, anyway. I'm open to correction just as I tried to correct the parent, if needed. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 20:40:41 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: (See EAPI-3, now preapproved, but conditional on feature implementation, with removal of some feature or other possible before final approval if not all PMs support it in a timely manner.) EAPI 3's approval is based upon implementation in Portage, not implementation in every other package manager. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 21:03:46 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb Ryan Hill: On Fri, 15 May 2009 23:31:25 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Wrong. For example: - stuff like docompress may change the content being installed depending on the package manager - --disable-static (maybe in a later EAPI) changes content - slot-dep-operators change the rdepend of installed packages, so it changes how the package manager has to handle reverse packages on uninstall (in EAPI 3) None of which are a problem when changing the EAPI from 0 to 1, which is the situation here. The first two examples fall under the currently established guideline of revbumping when content changes (and I emphasize guideline). I don't see how the third example is any different than adding or removing dependencies, which also does not require a revbump. Which is mostly wrong as well since a change in dependency means that the currently installed stuff may break if a package (the new dependency for example) gets removed and since the package you changed does not reference it, it gets broken (for example if you had a magic dep before and add it now as an explicit dep). I don't understand. Removing a runtime dependency of a package will break it regardless of whether or not it's referenced in the package's VDB. We don't prevent uninstalling dependencies, so how does having it referenced prevent breakage? The only case I can think of is depclean, but it already checks to see if removing a package will break the linkage map of another installed package. So, unless you're doing a pkgmove it's a dangerous thing since the PM can't reliably track reverse deps when doing uninstalls since it has to use the vdb entry for that, doesn't it? Since when do we track reverse deps for uninstalls? So I'd argue that an EAPI change does not require a revision bump in and of itself. EAPI may imply a decent implicit change to the ebuild and therefore needs a rev-bump as per the manual. Exactly. :) It's not the EAPI itself that requires the revbump, it's the changes the EAPI makes. That's all I'm saying. And in the case of going from EAPI 0 to EAPI 1, the changes are not those that require a revbump. If I were going from EAPI 1 to 2, and I'm using the default src_compile, then yes, a revbump is in order. We may want to document a suggested waiting time before removing ebuilds using older EAPI's. For example, should we always keep an EAPI 0 ebuild in stable as a fallback? Or if the user tries to install or update a package where all versions are masked by EAPI, should (does?) portage suggest updating itself? It would maybe suggest to update to an unstable version of portage, not so good then? If the user is installing a package that doesn't have a stable version with an EAPI that their package manager supports, then it's no different than if they are installing a package that doesn't have a stable version with their KEYWORDS. And when unmasking ~arch packages, you often have to unmask ~arch dependencies. Portage is just another of these dependencies. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI Changes
2009-05-17 22:51:50 Ryan Hill napisał(a):
On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller dev-z...@gentoo.org wrote:
So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?
Since when do we track reverse deps for uninstalls?
Portage supports `emerge --depclean ${package}` command which checks reverse
dependencies.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP54 vs. package.mask (was: Council meeting summary for meeting on May 14, 2009)
2009/5/17 Thomas de Grenier de Latour tom...@free.fr: On 2009/05/17, Thomas Anderson gentoofa...@gentoo.org wrote: - Vote on GLEP 54 This vote was called for by dertobi123. The vote was on whether to approve GLEP 54 conditional on whether GLEP 55 is passed. The reason for this is that GLEP 54 is unimplementable without the problems mentioned in GLEP 55 being solved. Conclusion: Conditionally approved on whether GLEP 55 is approved. Sorry if the question has already been raised (i would be surprised it was not), but... Back in january [1], it was decided that base profile (and thus package.mask) should stay in EAPI=0 syntax. So once you've approved GLEP55 (or an alternative) and introduced an EAPI with support for -scm suffix, how will you package.mask this new-style live ebuilds? You set KEYWORDS=. If you need to do something in profiles with it you can use profile eapis. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] rfc: information on localstatedir
On Sunday 17 May 2009 15:55:55 William Hubbs wrote: On Sun, May 17, 2009 at 02:57:47PM -0400, Mark Loeser wrote: According to FHS we are doing it right: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATI ON I guess what I would really like to know is...why does it matter? If something is configurable like that, then it should work regardless of what is put in. I guess it doesn't matter to me really; I was just looking for why we do it the way we do since one of the brltty devs strongly recommended that we change our build environment. the GNU guys prefer /var which is why that is also the default. we pick /var/lib because that's how FHS works and it results in a clean /var base tree. not many packages out there will manually split things up. if your package is special and does, then using /var in your ebuild is OK, but most dont. i.e. what we're doing is correct and their strong recommendation is wrong for the default. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 20:40:41 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Ryan Hill dirtye...@gentoo.org posted 2009051752.133c7...@halo.dirtyepic.sk.ca, excerpted below, on Sun, 17 May 2009 11:11:52 -0600: Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) As soon as a version of portage supporting that EAPI is available. That's a dangerous position to take. See experimental EAPIs for instance, sometimes temporarily supported by portage, but NOT for use in the tree. But I think you knew that and simply made some assumptions with the statement that not all readers may have. Yes, viewers at home, I'm speaking technically not politically. Technically you could add ebuilds for any EAPI the PM supports to the tree without affecting users. Politically, your fellow developers would stone you to death, put you in a sack, and drop you to the bottom of the sea. They might even revoke your commit access too. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
Let me first say that I think this revision is much improved, and makes it clearer what we are talking about. As to the stated problem(s): 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. GLEP54 is a valid use case, and I can see the value in that. Even so, using - and variations has worked for us so far, so I'm not convinced GLEP5455 as a package is a must have. 4. Use newer bash features This, in my opinion, would potentially be very useful to have. Altho it is certainly possible to continue with bash 3.0 as we have done so far, certain newer features are nice to be able to use. All in all I am still not sold on the perceived problems, and therefor a solution is in my eyes not strictly necessary. Having said that, I do understand people wanting support for newer bash features and GLEP54, so let's look at the possible solutions that have been proposed. Jorge Manuel B. S. Vicetto wrote: Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. Me too. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? In this case, I'd prefer .eb extension as well. EAPI to be somewhere near the top, I don't care that much about the exact implementation. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. I'd rather go for .geb as second choice. I'd rather go shorter than longer. Robert Buchholz wrote: Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild From what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that introduces changes as described in the Current behaviour section. (4) would otherwise keep the current workflow the same except restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that do not carry a metadata cache (overlays) which use new EAPIs also keep their portage version current. I'd say go with option (4) now and by the time EAPI 4 is collected, written up, agreed upon and implemented, enough time went by so we would not have to introduce an artificial delay. And after that, there won't be any delay to avoid breakage anymore. This would still have my preference. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 23:00:21 +0200
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote:
2009-05-17 22:51:50 Ryan Hill napisał(a):
On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller dev-z...@gentoo.org wrote:
So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?
Since when do we track reverse deps for uninstalls?
Portage supports `emerge --depclean ${package}` command which checks reverse
dependencies.
But it also checks link level dependencies as well, doesn't it?
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
On Sun, 17 May 2009 15:19:17 -0600
Ryan Hill dirtye...@gentoo.org wrote:
On Sun, 17 May 2009 23:00:21 +0200
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com wrote:
2009-05-17 22:51:50 Ryan Hill napisał(a):
On Sun, 17 May 2009 21:03:46 +0200
Tiziano Müller dev-z...@gentoo.org wrote:
So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?
Since when do we track reverse deps for uninstalls?
Portage supports `emerge --depclean ${package}` command which checks
reverse dependencies.
But it also checks link level dependencies as well, doesn't it?
halo ~ # grep chmlib /var/db/pkg/app-text/xchm-1.16/*
halo ~ # cat /var/db/pkg/app-text/xchm-1.16/NEEDED
/usr/bin/xchm
libwx_gtk2u_aui-2.8.so.0,libwx_gtk2u_html-2.8.so.0,libwx_gtk2u_core-2.8.so.0,libwx_baseu_net-2.8.so.0,libwx_baseu-2.8.so.0,libchm.so.0,libstdc++.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6
halo ~ # cat /var/db/pkg/app-text/xchm-1.16/NEEDED.ELF.2
X86_64;/usr/bin/xchm;;;libwx_gtk2u_aui-2.8.so.0,libwx_gtk2u_html-2.8.so.0,libwx_gtk2u_core-2.8.so.0,libwx_baseu_net-2.8.so.0,libwx_baseu-2.8.so.0,libchm.so.0,libstdc++.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6
halo ~ # emerge --depclean -pv chmlib
Calculating dependencies... done!
Checking for lib consumers...
Assigning files to packages...
* In order to avoid breakage of link level dependencies, one or more
* packages will not be removed. This can be solved by rebuilding the
* packages that pulled them in.
*
* dev-libs/chmlib-0.39-r1 pulled in by:
* app-text/xchm-1.16
*
Adding lib providers to graph...
-
Calculating dependencies... done!
dev-libs/chmlib-0.39-r1 pulled in by:
app-text/xchm-1.16
No packages selected for removal by depclean
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
Ciaran McCreesh wrote: 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. I actually like the current format in that it does *not* allow - in the version. For example, pkg-2.3.1_rc5 makes it clear that the string from 2 to rc5 is the version. If were were to allow pkg-2.3.1-rc5, this could get visually confusing (looks a bit like pkg-2.3.1-r5). In this case, *less* flexibility and more strict rules serve a good purpose, I think. -Joe
Re: [gentoo-dev] GLEP 55 updated
Ciaran McCreesh wrote: On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. I haven't come across any horrible hacks, that I'm aware of, but of course my interest is only in certain parts of the tree. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. Because we say so. We have chosen to do it a certain way. This works. It's uniform, it's simple, and therefor has a certain beauty to it. I see no pressing reason why we should start allowing alternative forms. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 00:08:05 +0200 Ben de Groot yng...@gentoo.org wrote: There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. I haven't come across any horrible hacks, that I'm aware of, but of course my interest is only in certain parts of the tree. Read the glibc ebuilds sometime. Notice the 'eblits' nonsense. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. There's a difference between the clean unsupported EAPIs are treated as masked behaviour you get with EAPIs done properly, and the horrible spammy errors you get if they aren't. New global scope functions cause the latter; new EAPIs done cleanly cause only the former. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. Because we say so. We have chosen to do it a certain way. This works. It's uniform, it's simple, and therefor has a certain beauty to it. I see no pressing reason why we should start allowing alternative forms. It's an utterly arbitrary restriction. Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Ben de Groot yng...@gentoo.org: Ciaran McCreesh wrote: On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Ciaran McCreesh wrote: Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. Upstreams use all sorts of strange versioning schemes. Here is a small collection: 1_14 - 1.14(app-emacs/limit) 1.0pre4- 1.0_pre4(app-emacs/cedet) 1.9.1-preview1 - 1.9.1_pre1 (app-emacs/ruby-mode) 2.0b6 - 2.0_beta6 (app-emacs/chess) 12B5 - 12.2.5 (dev-lang/erlang) 0.28 - 28.0(dev-lang/c-intercal, minor.major) -0.74 - ?? (SmallEiffel, negative version number) 1.-94.-2 - ?? (CLC-Intercal, negative components) We have to draw the borderline somewhere, and I think our current rules are a reasonable compromise. Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 00:54:04 +0200 Ulrich Mueller u...@gentoo.org wrote: Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. Upstreams use all sorts of strange versioning schemes. Here is a small collection: And we can handle a lot more of them sensibly than we currently do. We can't cover everything, but of these: 1_14 - 1.14(app-emacs/limit) 1.0pre4- 1.0_pre4(app-emacs/cedet) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. 1.9.1-preview1 - 1.9.1_pre1 (app-emacs/ruby-mode) This we could handle easily if there are more things using -preview. 2.0b6 - 2.0_beta6 (app-emacs/chess) This we can't sensibly, since most people using b use it as a 'greater than' thing. 0.28 - 28.0(dev-lang/c-intercal, minor.major) -0.74 - ?? (SmallEiffel, negative version number) 1.-94.-2 - ?? (CLC-Intercal, negative components) These are upstreams being deliberately silly, so we can ignore them. We have to draw the borderline somewhere, and I think our current rules are a reasonable compromise. Forbidding -rc is not a reasonable compromise... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Ciaran McCreesh wrote: 1_14 - 1.14(app-emacs/limit) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 01:11:45 +0200 Ulrich Mueller u...@gentoo.org wrote: On Sun, 17 May 2009, Ciaran McCreesh wrote: 1_14 - 1.14(app-emacs/limit) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009, Ciaran McCreesh wrote: How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. In fact, with GLEP 54 we have the problem already now. P=foo-1a-scm could mean both of the following: PN=foo PV=1a-scm PN=foo-1a PV=scm Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 01:30:26 +0200 Ulrich Mueller u...@gentoo.org wrote: On Mon, 18 May 2009, Ciaran McCreesh wrote: How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. In fact, with GLEP 54 we have the problem already now. P=foo-1a-scm could mean both of the following: PN=foo PV=1a-scm PN=foo-1a PV=scm We've had that problem ever since -100dpi things had to be made legal, and the horrible mess explaining the splitting rules in PMS came about from the last time we had this discussion. This isn't anything new -- it's just something we have to define very carefully. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] GLEP 54 and hyphens in PV (was: GLEP 55 updated)
On Mon, 18 May 2009, Ciaran McCreesh wrote: In fact, with GLEP 54 we have the problem already now. P=foo-1a-scm could mean both of the following: PN=foo PV=1a-scm PN=foo-1a PV=scm We've had that problem ever since -100dpi things had to be made legal, But so far you can split P into PN and PV at the last hyphen, because it is guaranteed that PV contains no hyphens. Trouble starts if hyphens in PV are allowed. Ulrich
Re: [gentoo-dev] GLEP 54 and hyphens in PV (was: GLEP 55 updated)
On Mon, 18 May 2009 01:43:43 +0200 Ulrich Mueller u...@gentoo.org wrote: Trouble starts if hyphens in PV are allowed. You mean like -r0? It's easily solved by a careful definition, in any case, just the same way that there's already a careful definition full of weaselling out to allow other abuses... There's no ambiguity so long as the definition is sound. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-05-17 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-05-17 23h59 UTC. Removals: net-www/adobesvg2009-05-12 15:12:45 ulm dev-tcltk/tkdiff2009-05-12 19:22:52 mescalinum media-sound/ermixer 2009-05-13 03:53:58 darkside media-sound/cdmp3 2009-05-13 03:57:04 darkside net-libs/zapata 2009-05-13 03:58:59 darkside sys-apps/gli2009-05-13 04:02:17 darkside sys-apps/tinylogin 2009-05-13 04:03:48 darkside net-misc/udhcp 2009-05-13 04:05:07 darkside kde-misc/kleansweep 2009-05-14 07:35:30 mr_bones_ net-mail/gotmail2009-05-14 07:40:18 tove dev-java/ant-tasks 2009-05-15 22:15:03 caster dev-tex/xkeyval 2009-05-17 01:01:54 ulm app-text/xetex 2009-05-17 01:03:29 ulm Additions: media-libs/libcue 2009-05-12 09:23:01 ssuominen sys-fs/aufs22009-05-12 17:36:00 tommy app-admin/eselect-maven 2009-05-12 19:08:16 ali_bush dev-util/tkdiff 2009-05-12 19:11:52 mescalinum app-laptop/lenovo-sl-laptop 2009-05-13 23:19:02 yngwin dev-perl/Test-use-ok2009-05-14 14:34:18 tove dev-libs/libusb-compat 2009-05-14 23:26:56 robbat2 virtual/libusb 2009-05-14 23:33:47 robbat2 dev-libs/libexecinfo2009-05-15 07:22:15 aballier profiles/arch/sparc-fbsd2009-05-16 09:17:28 aballier dev-ruby/ruby-hmac 2009-05-16 09:58:37 graaff dev-ruby/oauth 2009-05-16 10:31:15 graaff app-emulation/playonlinux 2009-05-16 10:48:22 volkmar dev-ruby/mash 2009-05-16 20:25:31 graaff dev-perl/File-Scan-ClamAV 2009-05-17 08:44:19 dertobi123 profiles/releases/freebsd-7.2 2009-05-17 10:53:41 aballier gnome-extra/wp_tray 2009-05-17 12:58:17 dertobi123 media-libs/libbs2b 2009-05-17 14:00:02 chainsaw dev-libs/libgee 2009-05-17 22:33:55 eva -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-www/adobesvg,removed,ulm,2009-05-12 15:12:45 dev-tcltk/tkdiff,removed,mescalinum,2009-05-12 19:22:52 media-sound/ermixer,removed,darkside,2009-05-13 03:53:58 media-sound/cdmp3,removed,darkside,2009-05-13 03:57:04 net-libs/zapata,removed,darkside,2009-05-13 03:58:59 sys-apps/gli,removed,darkside,2009-05-13 04:02:17 sys-apps/tinylogin,removed,darkside,2009-05-13 04:03:48 net-misc/udhcp,removed,darkside,2009-05-13 04:05:07 kde-misc/kleansweep,removed,mr_bones_,2009-05-14 07:35:30 net-mail/gotmail,removed,tove,2009-05-14 07:40:18 dev-java/ant-tasks,removed,caster,2009-05-15 22:15:03 dev-tex/xkeyval,removed,ulm,2009-05-17 01:01:54 app-text/xetex,removed,ulm,2009-05-17 01:03:29 Added Packages: media-libs/libcue,added,ssuominen,2009-05-12 09:23:01 sys-fs/aufs2,added,tommy,2009-05-12 17:36:00 app-admin/eselect-maven,added,ali_bush,2009-05-12 19:08:16 dev-util/tkdiff,added,mescalinum,2009-05-12 19:11:52 app-laptop/lenovo-sl-laptop,added,yngwin,2009-05-13 23:19:02 dev-perl/Test-use-ok,added,tove,2009-05-14 14:34:18 dev-libs/libusb-compat,added,robbat2,2009-05-14 23:26:56 virtual/libusb,added,robbat2,2009-05-14 23:33:47 dev-libs/libexecinfo,added,aballier,2009-05-15 07:22:15 profiles/arch/sparc-fbsd,added,aballier,2009-05-16 09:17:28 dev-ruby/ruby-hmac,added,graaff,2009-05-16 09:58:37 dev-ruby/oauth,added,graaff,2009-05-16 10:31:15 app-emulation/playonlinux,added,volkmar,2009-05-16 10:48:22 dev-ruby/mash,added,graaff,2009-05-16 20:25:31 dev-perl/File-Scan-ClamAV,added,dertobi123,2009-05-17 08:44:19 profiles/releases/freebsd-7.2,added,aballier,2009-05-17 10:53:41 gnome-extra/wp_tray,added,dertobi123,2009-05-17 12:58:17 media-libs/libbs2b,added,chainsaw,2009-05-17 14:00:02 dev-libs/libgee,added,eva,2009-05-17 22:33:55 Done.
[gentoo-dev] glibc-2.9 stabilization
if you've got something that needs to block glibc-2.9 going stable, now is the time to make it block Bug 270243. with us finally using glibc-2.8 and gcc-4.3.2, hopefully these core packages wont lag for so long. clicky link: http://bugs.gentoo.org/270243 -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 54 and hyphens in PV
On Mon, 18 May 2009, Ciaran McCreesh wrote:
Trouble starts if hyphens in PV are allowed.
You mean like -r0?
The revision is not part of PV. And it's easily split off, since the
string -rdigits cannot occur elsewhere in the package version.
It's easily solved by a careful definition, in any case, just the
same way that there's already a careful definition full of
weaselling out to allow other abuses... There's no ambiguity so long
as the definition is sound.
To come back to my example:
P=foo-1a-scm could mean both of the following:
PN=foo PV=1a-scm
PN=foo-1a PV=scm
AFAICS, there _is_ an ambiguity. You can have the following two
ebuilds in the tree, simultaneously:
${PORTDIR}/app-misc/foo/foo-1a-scm.ebuild
${PORTDIR}/app-misc/foo-1a/foo-1a-scm.ebuild
Which package will be pulled in by the following dependency?
RDEPEND==app-misc/foo-1a-scm
The conclusion is that GLEP 54 in its current form is not implementable.
(But maybe it would be possible to use a period instead of the hyphen?
That is, .live instead of -scm?)
Ulrich
