Re: [gentoo-dev] EAPI usage
Rich Freeman wrote: If I thought that bumping the EAPI would make my life as a maintainer easier I'd just do it - I wouldn't need a policy to tell me to do it. It is not only so much a question of whether it helps you as a maintainer but more whether it helps the user. And this is the case for all EAPIs which currently exist. I am surprised that nobody mentioned the following example: One of the arguments to introduce the user-patching code into EAPI=5 was that it should work for all packages - not randomly on some but not on others. So if in the course of time not all packages are bumped to at least EAPI=5, this goal cannot be reached by introducing the feature into the EAPI. If I did think that bumping the EAPI wasn't worth the hassle, and yet I was told that I'd be banned as a dev for not doing so anyway, then obviously I'm going to do the minimum necessary to comply with policy, which means changing the EAPI line of the ebuild and only changing other lines as required to get the thing to build and comply with PMS. This is sufficient for 99% of the ebuilds. So, while all those benefits you named are "enabled" few would actually be realized. For current EAPIs, most benefits are realized just by bumping EAPI. For instance, the improved error checking (i.e. dying on certain problems) happens automatically and might reveal problems which were hidden before. Also, for EAPI=5, other packages (possibly from overlays) can make use of slot dependencies from your packages. OK, for changing from setup tests for USE dependencies and USE_REQUIRE may require some extra coding (though not much), but again it is the _user_ who will gain from it a lot. So in any case, for the _user_ an EAPI bump is (with the current EAPIs) always a benefit. This should be worth to establish the policy currently. If this happens to be different in some hypothetical future EAPIs, this policy can be modified later, correspondingly: It is easy to change this policy later on, but hard to bump the whole tree later on. Martin Väth
Re: [gentoo-dev] EAPI usage
On Sun, Sep 2, 2012 at 6:52 AM, Vaeth wrote: > So in any case, for the _user_ an EAPI bump is (with the current EAPIs) > always a benefit. This should be worth to establish the policy currently. Your example only cited cases where an EAPI bump to 5 has a benefit. If that is the case, I'm fine with making an effort to migrate as many ebuilds as possible to EAPI 5. However, what is the benefit to users from migrating to EAPI 1, or 2, etc? The policy you're recommending would have required expending effort to implement every one of those for every ebuild in the tree without those kinds of end-user benefits. What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs are not numbers, and they aren't ordered either)? And since EAPIs aren't actually ordered, is the latest one whichever is actually last approved, or the one which is "most functional?" Suppose EAPI xml defines an ebuild format in xml that isn't parsed by bash, whose purpose is mainly to allow simple ebuilds to be simplified further but which is really only appropriate for 20% of the ebuilds in the tree? It isn't good to assume that newer EAPIs include all the features of the earlier ones - they just are different specifications for behavior. Maybe somebody will come up with a reason to have an EAPI that only works with packages that use cmake for building, or whatever. The bottom line is that it may be desirable in the future to have different branches of EAPIs followed by different packages. So, if we want to make a policy that we should use EAPI5 whenever possible I'm fine with that, if the benefits to users are worth the costs. However, why extend this to every EAPI that follows when the benefits of those are not yet known? Let's look at a different situation - --as-needed. It was realized that supporting this across the tree has significant benefits for users, so we made a push to make it happen. Packages that didn't support this had bugs filed, and they were fixed, and today it is the default. However, what we DIDN'T do is just make a policy that all packages have to support all possible options in LDFLAGS, but rather we just focused on the one we actually cared about. You don't even need a "policy" to enact these kinds of changes. There was never a policy that all ebuilds must support --as-needed, and there may be legitimate reasons for individual packages to not support it today. However, when the case was made that this benefits end-users then everybody just jumped on board, since, well, most of us are nice guys who do that sort of thing. :) Rich
Re: [gentoo-dev] EAPI usage
On 09/02/2012 12:52 PM, Vaeth wrote: > Rich Freeman wrote: > >> If I thought that bumping the EAPI would make my life as a maintainer >> easier I'd just do it - I wouldn't need a policy to tell me to do it. > > It is not only so much a question of whether it helps you as a > maintainer but more whether it helps the user. And this is the case > for all EAPIs which currently exist. > > I am surprised that nobody mentioned the following example: > > One of the arguments to introduce the user-patching code into EAPI=5 > was that it should work for all packages - not randomly on some but > not on others. So if in the course of time not all packages are > bumped to at least EAPI=5, this goal cannot be reached by introducing > the feature into the EAPI. global epatch_user has a downside which I think was not even really discussed here unless I missed something. It could introduce many bogus bug reports which are caused by user-applied patches, cause it's easier now and you don't need to do it in an overlay. The maintainer will need to catch this and asking which repo the bugreporter did use is not sufficient. He will need the build log and check if user patches got applied there. Always talking about the benefit for the user and not the time developers have to spend on things does not catch the whole situation. >> If I did think that bumping the EAPI wasn't worth the hassle, and yet >> I was told that I'd be banned as a dev for not doing so anyway, then >> obviously I'm going to do the minimum necessary to comply with policy, >> which means changing the EAPI line of the ebuild and only changing >> other lines as required to get the thing to build and comply with PMS. > > This is sufficient for 99% of the ebuilds. PMS is a fraction of what is to consider when writing an ebuild. It does not include QA policies, gentoo policies and whatnot. > >> So, while all those benefits you named are "enabled" few would >> actually be realized. > > For current EAPIs, most benefits are realized just by bumping EAPI. > For instance, the improved error checking (i.e. dying on certain problems) > happens automatically and might reveal problems which were hidden before. dying on certain problems can be achieved without EAPI bump. > > Also, for EAPI=5, other packages (possibly from overlays) can make use > of slot dependencies from your packages. > > OK, for changing from setup tests for USE dependencies and USE_REQUIRE > may require some extra coding (though not much), but again it is > the _user_ who will gain from it a lot. > If a user wants/needs features of newer EAPIs, because he does some things in his overlay, he could probably open a bug report with a proposed patch to the ebuild which bumps the EAPI. Unless that's the case I would leave it to the developer if he needs those features or what EAPI he prefers. If a newer EAPI would fix a bug it might still be solvable without EAPI-bump. Again: leave it to the developer. This will create a useless annoyance and I can assure you that developers WILL ignore this policy/rule. What are you gonna do then? Just bump it on your own without asking? Take it up to devrel? It's not really worth it. The benefits have been stated and it's already advised that developers keep up with the latest EAPI, but you _cannot_ assume it anyway like some PMS contributors do.
Re: [gentoo-dev] EAPI usage
On Sun, Sep 2, 2012 at 8:03 AM, hasufell wrote: > PMS is a fraction of what is to consider when writing an ebuild. It does > not include QA policies, gentoo policies and whatnot. True, although at least somebody bothers to write PMS down... Much of the rest is word of mouth, posts on mailing lists, maybe council meeting minutes, and whatever somebody decides to put in a bug report or ping you with on IRC. There are the GLSAs, and then stuff like guides and the devmanual, which are a blend of must-do, best practices (which presumably are discretionary), and just illustrative examples. Bottom line is that what a developer MUST do is a matter of what people will bother to complain to Devrel about, and what Devrel will bother to enforce. For the most part this boils down to common sense. That's why most "developers must do foo" proposals don't end up going anywhere. In six months somebody new will join the project and not even know what they "must" do simply by virtue of the fact that we won't bother to write it down anyway. Rich
Re: [gentoo-dev] EAPI usage
> > [...] > > standards. So, we declare that gcc-4.5 has to be enough for everyone, > > we'll just keep it in tree forever and dont bother anymore with all > > these superfluous "does not build with gcc-4.7" bugs. > > That is not an appropriate analogy, as I'm not suggesting that we > refuse to support newer EAPIs. I'm just saying that packages > shouldn't be bumped just for the sake of bumping them. Well I'm also not "suggesting" that we refuse to support newer gcc. Just, if a package does not build with newer, meh, why care. Take old one. > I might see some benefit for devs who routinely modify stuff that they > don't maintain, but that should generally be kept to a minimum anyway. > If unsure how how to edit any particular ebuild, just file a bug! > And if the package isn't maintained, then nobody will be bumping its > EAPI anyway. True but... we do have some fluctuation, and developers come and go. Who can update the ebuild better, someone who has maintained it for a while and is familiar with its details and the current eapis, or someone who has just picked up its pieces. What I dont actually understand at all is why bumping the EAPI should be so complicated or involved that it even deserves so much resistance... OK there may be miraculous eclasses (or one in particular) which change api radically from eapi to eapi, but I think we've already decided long time ago that this is a bad thing(tm) and should not be done. So let's hope it will not happen again. Other than that, I can not remember any ebuild where the EAPI bump alone took me more than 5min. Now take the frequency of new eapi's coming out, and compare it with the time that you need for a version bump of a package anyway (check upstream changelog, verify dependencies have not changed, do a test build, check for correct installation locations, ...) As an additional bonus this keeps your memory fresh about all the great new features... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
> Bottom line is that what a developer MUST do is a matter of what
> people will bother to complain to Devrel about, and what Devrel will
> bother to enforce. For the most part this boils down to common sense.
Err... if that's the part you worry about, I'm personally completely happy if
we just all agree that it's common sense to stick to the newest council-
approved development with fullest feature set. no need to put it in writing
any more than as a "strong recommendation". :)
> And since EAPIs
> aren't actually ordered, is the latest one whichever is actually last
> approved, or the one which is "most functional?" Suppose EAPI xml
To be honest I personally consider that ("eapis are not ordered") an
abomination, and my personal wish would be to keep them large-scale ordered
with (among one major version) unordered sub-versions ("4-xxx") if needed. or
at least keep all PMS-approved eapis ordered. "Experimental eapis for use in
third party software" should not require any mentioning in pms anyway. :]
However, that is a different discussion. Someday I'll start a separate
flamewar^H^H^H^H^H^H^Hmailing list thread about it.
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel wrote: > What I dont actually understand at all is why bumping the EAPI should be so > complicated or involved that it even deserves so much resistance... Ok, it REALLY annoys me when people pull out this kind of a line in an argument... If it isn't all that complicated or involved and it just makes so much sense, then why do we bother to waste time asking for it to be made policy, since obviously everybody will just do it anyway... Believe it or not, people who take up an opposing side in a debate don't ALWAYS do it because they're simply dumber than you. That is, unless they're arguing with me... :) > > As an additional bonus this keeps your memory fresh about all the great new > features... Yes, but keeping around all those old EAPIs keeps your memory fresh about how those ones work. As an additional bonus, you don't have to bother to figure out how the new ones work unless you actually need a feature offered by them. :) Rich
Re: [gentoo-dev] EAPI usage
On 09/02/2012 09:46 AM, Rich Freeman wrote: > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel > wrote: >> What I dont actually understand at all is why bumping the EAPI should be so >> complicated or involved that it even deserves so much resistance... > > Ok, it REALLY annoys me when people pull out this kind of a line > in an argument... If it isn't all that complicated or involved and it > just makes so much sense, then why do we bother to waste time asking > for it to be made policy, since obviously everybody will just do it > anyway... > > Believe it or not, people who take up an opposing side in a debate > don't ALWAYS do it because they're simply dumber than you. That is, > unless they're arguing with me... :) > I think everyone would be happier if all ebuilds in the tree were EAPI4. On the other hand, Rich is right that making this a policy will have the opposite of the intended effect: developers just won't fix bugs in EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could easily spend a few hours on this). As a compromise, it could be made policy that "bump to EAPI=foo" bugs are valid. If someone would benefit from such a bump, he can file a bug and know that it won't be closed WONTFIX. On the other hand, the dev is under no more pressure than usual to do the bump.
[gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Hi, this is actually a fork of the HDEPEND thread (sorry for having diverged that much there). As I wrote in the other thread, the problem with PDEPEND is that there are two (or more) semantics: - PDEPENDs used as "suggestions" but yet being considered in the depgraph and actually installed. Usually "suggestion" PDEPENDs are just packages providing extra features, not strictly required for the package to work at all. - PDEPENDs used for breaking dependency cycles (no problem with that). That is why I'd like to propose to introduce SDEPEND, with the following, simple, semantics: dependencies listed in SDEPEND are not required at build time nor strictly at runtime and they just enable more features in the installed application. There can be "use?" literals and by default, PMS should not pull them in in the dependencies calculation if not specifically asked (through argument or configuration file or else -- like it happens with binpkgs and --with-bdeps). A bunch of advantages over GLEP 62: - Simplicity (really, as in KISS). SDEPENDs are easier to understand and deal with, both at PMS (code) and user levels. They are also straightforward to use in ebuilds (dev) and through emerge (user). [1] - The USE flags meaning doesn't really get "stretched" introducing obscure, unknown and dangerous possible side effects when deployed in the real(tm) world. I understand that there is some level of risk with SDEPENDs as well, but we've seen them already in Exherbo and they seem to work fine there (I've been told this). - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are just "suggested" dependencies after all! - No need to introduce funky cache invalidation logic for PMS aggressively using caching at several layers of their stack and that guarantee a consistent depgraph for the installed pkgs repository as well [2]. - Fixes the "dissociative identity disorder" of PDEPEND ;-). Disadvantages: - If SDEPEND contains USE flags, these are written in stone and cannot be changed without a rebuild. This is generally fine for source packages, a bit less for binpkgs, but not really a big deal IMO. - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are - mgorny will hate me (eheheheh) Discuss. [1] It took me more than 5 minutes to understand how GLEP 62 works in practice and this is not really good to me, for a simple feature like this. [2] From GLEP 62 page: "and it is not strictly required that a package manager must ensure that the dependency graph is still consistent afterwards". -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On 09/02/2012 04:45 PM, Fabio Erculiani wrote: > Hi, > this is actually a fork of the HDEPEND thread (sorry for having > diverged that much there). > As I wrote in the other thread, the problem with PDEPEND is that there > are two (or more) semantics: > > - PDEPENDs used as "suggestions" but yet being considered in the > depgraph and actually installed. Usually "suggestion" PDEPENDs are > just packages providing extra features, not strictly required for the > package to work at all. > - PDEPENDs used for breaking dependency cycles (no problem with that). > > That is why I'd like to propose to introduce SDEPEND, with the > following, simple, semantics: > dependencies listed in SDEPEND are not required at build time nor > strictly at runtime and they just enable more features in the > installed application. There can be "use?" literals and by default, > PMS should not pull them in in the dependencies calculation if not > specifically asked (through argument or configuration file or else -- > like it happens with binpkgs and --with-bdeps). > > A bunch of advantages over GLEP 62: > - Simplicity (really, as in KISS). SDEPENDs are easier to understand > and deal with, both at PMS (code) and user levels. They are also > straightforward to use in ebuilds (dev) and through emerge (user). [1] > - The USE flags meaning doesn't really get "stretched" introducing > obscure, unknown and dangerous possible side effects when deployed in > the real(tm) world. I understand that there is some level of risk with > SDEPENDs as well, but we've seen them already in Exherbo and they seem > to work fine there (I've been told this). > - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are > just "suggested" dependencies after all! > - No need to introduce funky cache invalidation logic for PMS > aggressively using caching at several layers of their stack and that > guarantee a consistent depgraph for the installed pkgs repository as > well [2]. > - Fixes the "dissociative identity disorder" of PDEPEND ;-). > > Disadvantages: > - If SDEPEND contains USE flags, these are written in stone and cannot > be changed without a rebuild. This is generally fine for source > packages, a bit less for binpkgs, but not really a big deal IMO. > - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are > - mgorny will hate me (eheheheh) > > Discuss. > > [1] It took me more than 5 minutes to understand how GLEP 62 works in > practice and this is not really good to me, for a simple feature like > this. > [2] From GLEP 62 page: "and it is not strictly required that a package > manager must ensure that the dependency graph is still consistent > afterwards". Why not introduce a global useflag such as "suggested-deps" which complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote: > > > Why not introduce a global useflag such as "suggested-deps" which > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. > How do you manage to fix the PDEPEND "identity disorder" problem then? Teaching devs to move to GLEP 62 is much harder than just telling them to move dep strings to more appropriate locations. Moreover, your solution just makes the USE flags abuse situation worse: there are packages that use USE flags just to include extra, optional packages in the dependencies... See USE=bluetooth in net-misc/networkmanager for example (this is what I mean with USE flags abuse, actually). I'm not saying that SDEPEND is the best one-size-fits-all solution but you may agree that's the simplest and most effective one. -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 16:45:12 +0200 Fabio Erculiani wrote: > Hi, > this is actually a fork of the HDEPEND thread (sorry for having > diverged that much there). > As I wrote in the other thread, the problem with PDEPEND is that there > are two (or more) semantics: > > - PDEPENDs used as "suggestions" but yet being considered in the > depgraph and actually installed. Usually "suggestion" PDEPENDs are > just packages providing extra features, not strictly required for the > package to work at all. > - PDEPENDs used for breaking dependency cycles (no problem with that). > > That is why I'd like to propose to introduce SDEPEND, with the > following, simple, semantics: > dependencies listed in SDEPEND are not required at build time nor > strictly at runtime and they just enable more features in the > installed application. There can be "use?" literals and by default, > PMS should not pull them in in the dependencies calculation if not > specifically asked (through argument or configuration file or else -- > like it happens with binpkgs and --with-bdeps). > > A bunch of advantages over GLEP 62: > - Simplicity (really, as in KISS). SDEPENDs are easier to understand > and deal with, both at PMS (code) and user levels. They are also > straightforward to use in ebuilds (dev) and through emerge (user). [1] > - The USE flags meaning doesn't really get "stretched" introducing > obscure, unknown and dangerous possible side effects when deployed in > the real(tm) world. I understand that there is some level of risk with > SDEPENDs as well, but we've seen them already in Exherbo and they seem > to work fine there (I've been told this). > - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are > just "suggested" dependencies after all! > - No need to introduce funky cache invalidation logic for PMS > aggressively using caching at several layers of their stack and that > guarantee a consistent depgraph for the installed pkgs repository as > well [2]. > - Fixes the "dissociative identity disorder" of PDEPEND ;-). > > Disadvantages: > - If SDEPEND contains USE flags, these are written in stone and cannot > be changed without a rebuild. This is generally fine for source > packages, a bit less for binpkgs, but not really a big deal IMO. > - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are > - mgorny will hate me (eheheheh) > > Discuss. > > [1] It took me more than 5 minutes to understand how GLEP 62 works in > practice and this is not really good to me, for a simple feature like > this. > [2] From GLEP 62 page: "and it is not strictly required that a package > manager must ensure that the dependency graph is still consistent > afterwards". Is it fifth thread on the same topic already? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 17:09:22 +0200 Fabio Erculiani wrote: > On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote: > > > > > > Why not introduce a global useflag such as "suggested-deps" which > > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. > > > > How do you manage to fix the PDEPEND "identity disorder" problem then? > Teaching devs to move to GLEP 62 is much harder than just telling them > to move dep strings to more appropriate locations. Much harder? So, devs today don't know how USE flags work? Or do you implying that devs should know bare technical details of package manager implementation? Or is it just an-ass argument to support an ass-thesis? > Moreover, your solution just makes the USE flags abuse situation > worse: there are packages that use USE flags just to include extra, > optional packages in the dependencies... See USE=bluetooth in > net-misc/networkmanager for example (this is what I mean with USE > flags abuse, actually). No, it fixes it. It enables those packages to use the same solution, fixing its downsides. > I'm not saying that SDEPEND is the best one-size-fits-all solution but > you may agree that's the simplest and most effective one. pkg_postinst() is simpler. USE flags are simple and very effective, yet incorrect. An effective SDEPEND implementation is definitely nowhere close to simple. Nor is presenting those dependencies to users. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny wrote: > On Sun, 2 Sep 2012 17:09:22 +0200 > Fabio Erculiani wrote: > >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote: >> > >> > >> > Why not introduce a global useflag such as "suggested-deps" which >> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. >> > >> >> How do you manage to fix the PDEPEND "identity disorder" problem then? >> Teaching devs to move to GLEP 62 is much harder than just telling them >> to move dep strings to more appropriate locations. > > Much harder? So, devs today don't know how USE flags work? Or do you > implying that devs should know bare technical details of package > manager implementation? Or is it just an-ass argument to support > an ass-thesis? For instance, the amount of devs still improperly using pkg_setup for build-time stuff, after years that they've been told to not do that, is a good example of how, while we're great, we tend to be resilient to change. This goes beyond software engineering, this is about psychology. The more one thing is simple, the faster is recognized and properly used by people. Not to mention that I am one of the PMS writers here (Entropy cough), and I know how much harder implementing runtime-switchable USE flags is, compared to a simple SDEPEND solution. > >> Moreover, your solution just makes the USE flags abuse situation >> worse: there are packages that use USE flags just to include extra, >> optional packages in the dependencies... See USE=bluetooth in >> net-misc/networkmanager for example (this is what I mean with USE >> flags abuse, actually). > > No, it fixes it. It enables those packages to use the same solution, > fixing its downsides. It looks like it just tries to workaround the issue, not fix it to its roots (PDEPEND is ill!). > >> I'm not saying that SDEPEND is the best one-size-fits-all solution but >> you may agree that's the simplest and most effective one. > > pkg_postinst() is simpler. USE flags are simple and very effective, yet > incorrect. Could you tell me how would you plan to implement so API to read "suggested" dependencies from pkg_postinst() output? I understand that being API-friendly is not really the best feature of Portage and ebuilds in general (one reason why our PackageKit backend is a bit sucky) but this is not a good reason to keep doing things like they've been always done. (Information printed at pkg_postinst() is another interesting problem, wrt API consumers, and this includes PackageKit, but I don't want to drift away too much from the topic). > > An effective SDEPEND implementation is definitely nowhere close > to simple. Nor is presenting those dependencies to users. As I mentioned above, I know what it simple and what not, from a Software Engineering point of view. And SDEPENDs are much simpler than GLEP 62, and GLEP 62 does not fix the PDEPEND issue because individuals will keep using it because at the end of the day, it is order of magniture simpler than obscure new variables and USE flags. As a rule of thumb, "simple" always shines over the complex and convoluted in the long run. > > -- > Best regards, > Michał Górny Peace & love! -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 17:51:00 +0200 Fabio Erculiani wrote: > On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny > wrote: > > On Sun, 2 Sep 2012 17:09:22 +0200 > > Fabio Erculiani wrote: > > > >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell > >> wrote: > >> > > >> > > >> > Why not introduce a global useflag such as "suggested-deps" which > >> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. > >> > > >> > >> How do you manage to fix the PDEPEND "identity disorder" problem > >> then? Teaching devs to move to GLEP 62 is much harder than just > >> telling them to move dep strings to more appropriate locations. > > > > Much harder? So, devs today don't know how USE flags work? Or do you > > implying that devs should know bare technical details of package > > manager implementation? Or is it just an-ass argument to support > > an ass-thesis? > > For instance, the amount of devs still improperly using pkg_setup for > build-time stuff, after years that they've been told to not do that, > is a good example of how, while we're great, we tend to be resilient > to change. This goes beyond software engineering, this is about > psychology. The more one thing is simple, the faster is recognized and > properly used by people. > > Not to mention that I am one of the PMS writers here (Entropy cough), > and I know how much harder implementing runtime-switchable USE flags > is, compared to a simple SDEPEND solution. Yes, I'm aware of that. You're trying to force a worse solution because it is easier for you to implement in your partial package manager. > >> Moreover, your solution just makes the USE flags abuse situation > >> worse: there are packages that use USE flags just to include extra, > >> optional packages in the dependencies... See USE=bluetooth in > >> net-misc/networkmanager for example (this is what I mean with USE > >> flags abuse, actually). > > > > No, it fixes it. It enables those packages to use the same solution, > > fixing its downsides. > > It looks like it just tries to workaround the issue, not fix it to its > roots (PDEPEND is ill!). It is invalid to use those packages in PDEPEND; even Ciaran will tell you that. > >> I'm not saying that SDEPEND is the best one-size-fits-all solution > >> but you may agree that's the simplest and most effective one. > > > > pkg_postinst() is simpler. USE flags are simple and very effective, > > yet incorrect. > > Could you tell me how would you plan to implement so API to read > "suggested" dependencies from pkg_postinst() output? > I understand that being API-friendly is not really the best feature of > Portage and ebuilds in general (one reason why our PackageKit backend > is a bit sucky) but this is not a good reason to keep doing things > like they've been always done. > (Information printed at pkg_postinst() is another interesting problem, > wrt API consumers, and this includes PackageKit, but I don't want to > drift away too much from the topic). > > > > > An effective SDEPEND implementation is definitely nowhere close > > to simple. Nor is presenting those dependencies to users. > > As I mentioned above, I know what it simple and what not, from a > Software Engineering point of view. And SDEPENDs are much simpler than > GLEP 62, and GLEP 62 does not fix the PDEPEND issue because > individuals will keep using it because at the end of the day, it is > order of magniture simpler than obscure new variables and USE flags. > As a rule of thumb, "simple" always shines over the complex and > convoluted in the long run. As long as it's complete. A simple incomplete solution is yet another hack which will have to be worked-around in the future again. And you'll end up with 5 different solutions which will have to somehow work together to solve a single problem (see: exheres). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI usage
On Sun, 02 Sep 2012 14:03:07 +0200 hasufell wrote: > On 09/02/2012 12:52 PM, Vaeth wrote: > > Rich Freeman wrote: > > > >> If I thought that bumping the EAPI would make my life as a > >> maintainer easier I'd just do it - I wouldn't need a policy to > >> tell me to do it. > > > > It is not only so much a question of whether it helps you as a > > maintainer but more whether it helps the user. And this is the case > > for all EAPIs which currently exist. > > > > I am surprised that nobody mentioned the following example: > > > > One of the arguments to introduce the user-patching code into EAPI=5 > > was that it should work for all packages - not randomly on some but > > not on others. So if in the course of time not all packages are > > bumped to at least EAPI=5, this goal cannot be reached by > > introducing the feature into the EAPI. > > global epatch_user has a downside which I think was not even really > discussed here unless I missed something. It could introduce many > bogus bug reports which are caused by user-applied patches, cause > it's easier now and you don't need to do it in an overlay. > The maintainer will need to catch this and asking which repo the > bugreporter did use is not sufficient. He will need the build log and > check if user patches got applied there. it is probably easy to add a big warning 'user patches have been applied' when emerge bails out because a build failed
Re: [gentoo-dev] EAPI usage
On Sun, 02 Sep 2012 14:03:07 +0200 hasufell wrote: > global epatch_user has a downside which I think was not even really > discussed here unless I missed something. It could introduce many > bogus bug reports which are caused by user-applied patches, cause > it's easier now and you don't need to do it in an overlay. > The maintainer will need to catch this and asking which repo the > bugreporter did use is not sufficient. He will need the build log and > check if user patches got applied there. No, it's not a downside. It's an advantage: user patches will get applied correctly now, and in a way visible to the package mangler, and thus can be shown consistently in bug reports. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI usage
On Sun, 2 Sep 2012 15:23:58 +0200
"Andreas K. Huettel" wrote:
> To be honest I personally consider that ("eapis are not ordered") an
> abomination, and my personal wish would be to keep them large-scale
> ordered with (among one major version) unordered sub-versions
> ("4-xxx") if needed. or at least keep all PMS-approved eapis ordered.
> "Experimental eapis for use in third party software" should not
> require any mentioning in pms anyway. :]
I think you're missing the point of that declaration... It's fine for
you to think of EAPI 4 as being newer than EAPI 3. It's not fine for
you to consider EAPI 4 to be a superset of EAPI 3, and it's not fine to
try using comparisons other than string equality (with the annoying
special case for "" being "0") on an EAPI value.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 17:23:40 +0200 Michał Górny wrote: > An effective SDEPEND implementation is definitely nowhere close > to simple. Nor is presenting those dependencies to users. Indeed it's not, but we *do* have a reference implementation and lots of practical experience with it, and we have worked out all the difficulties. Having said that, if we're going with suggested dependencies for EAPI 5 (which I strongly suspect won't happen, since we seem to be wanting EAPI 5 now rather than in several years time...) then there's a lot more to getting it right than is mentioned in the original post, and it needs to be written up properly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh wrote: > and we have worked out all the difficulties. Please elaborate. What difficulties? What did you implement other than plain SDEPEND? With what features? Lots of detail missing. > > Having said that, if we're going with suggested dependencies for EAPI 5 > (which I strongly suspect won't happen, since we seem to be wanting > EAPI 5 now rather than in several years time...) then there's a lot > more to getting it right than is mentioned in the original post, and it > needs to be written up properly. Well, this depends on the quality of the PMS architecture, I am not familiar with Paludis tho. I don't remember to have listed anything about what needs to be done at the implementation level actually, nor I really wanted to. I always use the 5 minutes "rule of thumb" strategy to understand the complexity of proposals: if it takes me more than 5 minutes to understand it, then users (!= devs) will have to go through the same or more "wtf-period". And the probability of them "giving up / getting sick / ignoring it" is linear with the wtf-period. > > -- > Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] EAPI usage
On Sun, 2 Sep 2012 14:54:12 -0300 Alexis Ballier wrote: > On Sun, 02 Sep 2012 14:03:07 +0200 > hasufell wrote: > > > On 09/02/2012 12:52 PM, Vaeth wrote: > > > Rich Freeman wrote: > > > > > >> If I thought that bumping the EAPI would make my life as a > > >> maintainer easier I'd just do it - I wouldn't need a policy to > > >> tell me to do it. > > > > > > It is not only so much a question of whether it helps you as a > > > maintainer but more whether it helps the user. And this is the > > > case for all EAPIs which currently exist. > > > > > > I am surprised that nobody mentioned the following example: > > > > > > One of the arguments to introduce the user-patching code into > > > EAPI=5 was that it should work for all packages - not randomly on > > > some but not on others. So if in the course of time not all > > > packages are bumped to at least EAPI=5, this goal cannot be > > > reached by introducing the feature into the EAPI. > > > > global epatch_user has a downside which I think was not even really > > discussed here unless I missed something. It could introduce many > > bogus bug reports which are caused by user-applied patches, cause > > it's easier now and you don't need to do it in an overlay. > > The maintainer will need to catch this and asking which repo the > > bugreporter did use is not sufficient. He will need the build log > > and check if user patches got applied there. > > it is probably easy to add a big warning 'user patches have been > applied' when emerge bails out because a build failed Yes, and it is definitely easier to nice them than the fact that user has patched the ebuild silently. That said, I do not really remember users ever doing bogus bug reports. But well, every reason to complain is good, isn't it? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 20:46:19 +0200 Fabio Erculiani wrote: > On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh > wrote: > > and we have worked out all the difficulties. > > Please elaborate. What difficulties? What did you implement other than > plain SDEPEND? With what features? Lots of detail missing. The big issues you're ignoring: * What to do if a package has an SDEPEND upon cat/pkg[x] and the user has cat/pkg[-x] installed, or if another package in the resolution depends upon cat/pkg and the user hasn't specified USE=x. Similarly, an SDEPEND upon >=cat/pkg-2.1 and the user has cat/pkg-2.0 (which is in the same slot as 2.1) installed. The right answer is to force a reinstall with [x] / force the upgrade, and for the spec to explicitly require this from implementations, but *why* this is the case is fairly subtle. * How to handle groups of dependencies in suggestions. * How to display suggestions to the user, and allow the user to confirm or reject suggestions. From a spec perspective, we don't mandate any particular behaviour, but we do need to make sure that a good quality implementation is possible. With SDEPEND as you're proposing, we're going to have exactly the same issues we currently have with REQUIRED_USE and blockers: ebuilds won't provide enough information to provide a good user interface. * What use? blocks in SDEPEND actually mean. Again, there's a right answer here: it's for when a particular suggestion requires the base package to be built in a particular way. > > Having said that, if we're going with suggested dependencies for > > EAPI 5 (which I strongly suspect won't happen, since we seem to be > > wanting EAPI 5 now rather than in several years time...) then > > there's a lot more to getting it right than is mentioned in the > > original post, and it needs to be written up properly. > > Well, this depends on the quality of the PMS architecture, I am not > familiar with Paludis tho. Paludis already has it. The question is whether it can be implemented for Portage. > I don't remember to have listed anything about what needs to be done > at the implementation level actually, nor I really wanted to. That's a problem. You can't just magically describe a vague feature and expect it to be implementable. > I always use the 5 minutes "rule of thumb" strategy to understand the > complexity of proposals: if it takes me more than 5 minutes to > understand it, then users (!= devs) will have to go through the same > or more "wtf-period". And the probability of them "giving up / getting > sick / ignoring it" is linear with the wtf-period. There's a big difference between understanding things for developers, and getting it right for implementation. Where possible, users and developers should only need a shallow understanding of a feature to be able to use it, but for the purposes of the spec and the implementation, we need a proper deep understanding of the topic, and you aren't giving that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 19:08:33 +0100 Ciaran McCreesh wrote: > On Sun, 2 Sep 2012 17:23:40 +0200 > Michał Górny wrote: > > An effective SDEPEND implementation is definitely nowhere close > > to simple. Nor is presenting those dependencies to users. > > Indeed it's not, but we *do* have a reference implementation and lots > of practical experience with it, and we have worked out all the > difficulties. Yes, I am pretty sure you tested it with *many different* packages. Maybe even all packages you have in Exherbo. Could you give some actual numbers, and details? > Having said that, if we're going with suggested dependencies for EAPI > 5 (which I strongly suspect won't happen, since we seem to be wanting > EAPI 5 now rather than in several years time...) then there's a lot > more to getting it right than is mentioned in the original post, and > it needs to be written up properly. Good to hear that. I always appreciate constructive critics with an explanation what needs to be fixed. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 21:07:30 +0200 Michał Górny wrote: > On Sun, 2 Sep 2012 19:08:33 +0100 > Ciaran McCreesh wrote: > > On Sun, 2 Sep 2012 17:23:40 +0200 > > Michał Górny wrote: > > > An effective SDEPEND implementation is definitely nowhere close > > > to simple. Nor is presenting those dependencies to users. > > > > Indeed it's not, but we *do* have a reference implementation and > > lots of practical experience with it, and we have worked out all the > > difficulties. > > Yes, I am pretty sure you tested it with *many different* packages. > Maybe even all packages you have in Exherbo. Could you give some > actual numbers, and details? That depends. Are we seriously considering this for implementation on Gentoo at any time in the foreseeable future? Writing this all up properly is a lot of work, and I don't see much point in putting in the effort if it isn't going to go anywhere. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
It just covers the basic idea of getting includedir/libdir. As many
different packages require different hackeries, there is probably no
good way of handling that.
I'd appreciate further ideas, feedback, and possibly an example from
someone who will use it.
---
gx86/eclass/boost-utils.eclass | 76 ++
1 file changed, 76 insertions(+)
create mode 100644 gx86/eclass/boost-utils.eclass
diff --git a/gx86/eclass/boost-utils.eclass b/gx86/eclass/boost-utils.eclass
new file mode 100644
index 000..c878b16
--- /dev/null
+++ b/gx86/eclass/boost-utils.eclass
@@ -0,0 +1,76 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+if [[ ! ${_BOOST_ECLASS} ]]; then
+
+# @ECLASS: boost-utils.eclass
+# @MAINTAINER:
+# Michał Górny
+# Tiziano Müller
+# Sebastian Luther
+# Arfrever Frehtes Taifersar Arahesis
+# @BLURB: helper functions for packages using Boost C++ library
+# @DESCRIPTION:
+# Helper functions to be used when building packages using the Boost C++
+# library collection.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4) ;;
+ *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
+esac
+
+inherit multilib versionator
+
+# @ECLASS-VARIABLE: BOOST_MAX_VERSION
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The maximal (newest) boost version supported by the package. If unset,
+# the newest installed version will be used.
+#
+# Please note that if BOOST_MAX_VERSION is set, the package should
+# depend on boost packages with *exactly* that slot (i.e. boost:1.47);
+# otherwise, the package should depend on boost without a slot
+# specified (i.e. >=boost-1.45).
+
+# @FUNCTION: boost-utils_get_best_slot
+# @DESCRIPTION:
+# Get newest installed slot of Boost.
+boost-utils_get_best_slot() {
+ local pkg=dev-libs/boost
+ local atom=$(best_version ${pkg})
+ get_version_component_range 1-2 ${atom#${pkg}}
+}
+
+# @FUNCTION: boost-utils_get_includedir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the includedir for given Boost slot. If no slot is given, defaults
+# to ${BOOST_MAX_VERSION}. If that variable is unset, newest installed
+# slot will be used.
+#
+# Output the sole path (without -I).
+boost-utils_get_includedir() {
+ local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+
+ echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
+}
+
+# @FUNCTION: boost-utils_get_libdir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the libdir for given Boost slot. If no slot is given, defaults
+# to ${BOOST_MAX_VERSION}. If that variable is unset, newest installed
+# slot will be used.
+#
+# Output the sole path (without -L).
+boost-utils_get_libdir() {
+ local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+
+ echo -n "${EPREFIX}/usr/$(get_libdir)/boost-${slot/./_}"
+}
+
+_BOOST_ECLASS=1
+fi # _BOOST_ECLASS
--
1.7.12
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh wrote: > On Sun, 2 Sep 2012 20:46:19 +0200 > Fabio Erculiani wrote: >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh >> wrote: >> > and we have worked out all the difficulties. >> >> Please elaborate. What difficulties? What did you implement other than >> plain SDEPEND? With what features? Lots of detail missing. > > The big issues you're ignoring: And you call them "big issues"? Ah, the "you're ignoring" part looks a bit arrogant, are you short with arguments ;-) ? > > -- > Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 20:10:38 +0100 Ciaran McCreesh wrote: > On Sun, 2 Sep 2012 21:07:30 +0200 > Michał Górny wrote: > > On Sun, 2 Sep 2012 19:08:33 +0100 > > Ciaran McCreesh wrote: > > > On Sun, 2 Sep 2012 17:23:40 +0200 > > > Michał Górny wrote: > > > > An effective SDEPEND implementation is definitely nowhere close > > > > to simple. Nor is presenting those dependencies to users. > > > > > > Indeed it's not, but we *do* have a reference implementation and > > > lots of practical experience with it, and we have worked out all > > > the difficulties. > > > > Yes, I am pretty sure you tested it with *many different* packages. > > Maybe even all packages you have in Exherbo. Could you give some > > actual numbers, and details? > > That depends. Are we seriously considering this for implementation on > Gentoo at any time in the foreseeable future? Writing this all up > properly is a lot of work, and I don't see much point in putting in > the effort if it isn't going to go anywhere. Yes, we are. Zac was very positive about implementing it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, 2 Sep 2012 21:38:26 +0200 Fabio Erculiani wrote: > On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh > wrote: > > On Sun, 2 Sep 2012 20:46:19 +0200 > > Fabio Erculiani wrote: > >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh > >> wrote: > >> > and we have worked out all the difficulties. > >> > >> Please elaborate. What difficulties? What did you implement other > >> than plain SDEPEND? With what features? Lots of detail missing. > > > > The big issues you're ignoring: > > And you call them "big issues"? Based upon the amount of work it took to get them right for kdebuilds and then Exherbo, yes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
s/with/on/ -- Fabio Erculiani
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-02 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-09-02 23h59 UTC. Removals: sys-apps/chpax 2012-08-28 03:08:17 blueness dev-ruby/ruby-dbi 2012-09-02 08:28:02 flameeyes Additions: dev-python/figleaf 2012-08-27 10:54:06 xarthisius www-apps/bitten 2012-08-27 11:01:40 xarthisius dev-python/gevent-zeromq2012-08-27 13:35:44 ultrabug dev-python/gevent-websocket 2012-08-27 13:46:14 ultrabug dev-python/gevent-socketio 2012-08-27 13:52:49 ultrabug kde-misc/akonadi-social-utils 2012-08-27 14:14:45 johu dev-python/argh 2012-08-27 14:30:43 patrick dev-db/barman 2012-08-27 15:10:25 patrick media-sound/gnac2012-08-28 00:51:56 radhermit dev-db/bucardo 2012-08-28 03:03:37 patrick x11-misc/simpleswitcher 2012-08-28 11:29:44 xmw net-misc/csync 2012-08-28 12:25:19 scarabeus sys-auth/pam-csync 2012-08-28 12:38:44 scarabeus net-misc/mirall 2012-08-28 13:19:01 scarabeus games-roguelike/stone-soup 2012-08-28 23:17:53 hasufell dev-db/pgtune 2012-08-29 08:09:53 patrick net-libs/libnetfilter_acct 2012-08-31 19:46:00 pinkbyte net-firewall/nfacct 2012-08-31 19:52:16 pinkbyte dev-perl/DBIx-Safe 2012-09-01 02:21:28 patrick mail-filter/libdkim 2012-09-01 09:12:02 qnikst app-i18n/librime2012-09-01 10:42:58 yngwin app-i18n/rime-data 2012-09-01 10:46:21 yngwin app-i18n/fcitx-rime 2012-09-01 10:52:19 yngwin app-i18n/ibus-rime 2012-09-01 10:54:20 yngwin dev-ruby/httpauth 2012-09-02 07:47:53 graaff dev-ruby/jwt2012-09-02 07:56:42 graaff dev-ruby/dbi2012-09-02 08:25:56 flameeyes dev-libs/libixion 2012-09-02 16:24:27 scarabeus x11-misc/urxvt-perls2012-09-02 20:00:48 radhermit -- 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: sys-apps/chpax,removed,blueness,2012-08-28 03:08:17 dev-ruby/ruby-dbi,removed,flameeyes,2012-09-02 08:28:02 Added Packages: dev-python/figleaf,added,xarthisius,2012-08-27 10:54:06 www-apps/bitten,added,xarthisius,2012-08-27 11:01:40 dev-python/gevent-zeromq,added,ultrabug,2012-08-27 13:35:44 dev-python/gevent-websocket,added,ultrabug,2012-08-27 13:46:14 dev-python/gevent-socketio,added,ultrabug,2012-08-27 13:52:49 kde-misc/akonadi-social-utils,added,johu,2012-08-27 14:14:45 dev-python/argh,added,patrick,2012-08-27 14:30:43 dev-db/barman,added,patrick,2012-08-27 15:10:25 media-sound/gnac,added,radhermit,2012-08-28 00:51:56 dev-db/bucardo,added,patrick,2012-08-28 03:03:37 x11-misc/simpleswitcher,added,xmw,2012-08-28 11:29:44 net-misc/csync,added,scarabeus,2012-08-28 12:25:19 sys-auth/pam-csync,added,scarabeus,2012-08-28 12:38:44 net-misc/mirall,added,scarabeus,2012-08-28 13:19:01 games-roguelike/stone-soup,added,hasufell,2012-08-28 23:17:53 dev-db/pgtune,added,patrick,2012-08-29 08:09:53 net-libs/libnetfilter_acct,added,pinkbyte,2012-08-31 19:46:00 net-firewall/nfacct,added,pinkbyte,2012-08-31 19:52:16 dev-perl/DBIx-Safe,added,patrick,2012-09-01 02:21:28 mail-filter/libdkim,added,qnikst,2012-09-01 09:12:02 app-i18n/librime,added,yngwin,2012-09-01 10:42:58 app-i18n/rime-data,added,yngwin,2012-09-01 10:46:21 app-i18n/fcitx-rime,added,yngwin,2012-09-01 10:52:19 app-i18n/ibus-rime,added,yngwin,2012-09-01 10:54:20 dev-ruby/httpauth,added,graaff,2012-09-02 07:47:53 dev-ruby/jwt,added,graaff,2012-09-02 07:56:42 dev-ruby/dbi,added,flameeyes,2012-09-02 08:25:56 dev-libs/libixion,added,scarabeus,2012-09-02 16:24:27 x11-misc/urxvt-perls,added,radhermit,2012-09-02 20:00:48 Done.
[gentoo-dev] Re: EAPI usage
Michael Orlitzky posted on Sun, 02 Sep 2012 10:36:13 -0400 as excerpted: > As a compromise, it could be made policy that "bump to EAPI=foo" bugs > are valid. If someone would benefit from such a bump, he can file a bug > and know that it won't be closed WONTFIX. On the other hand, the dev is > under no more pressure than usual to do the bump. This looks like a reasonable compromise indeed. =:^) Tho I'd still suggest that like other "low priority" bugs, the package maintainer can still resolve it as LATER, BLUESKY (tho AFAIK gentoo's bugzilla doesn't have that one), or even WONTFIX (as opposed to INVALID). The bug should be considered valid, so INVALID isn't correct, but disallowing WONTFIX simply gets in the way of proper communication. If a package maintainer WONTFIX, it's better to let them actually SAY that, so the bug filer can get on with life, knowing they'll have to longterm maintain their own overlay copy if they want the EAPI bump bad enough, than to have the bug simply sit there, ignored. Talking about which. what about a resolution PATCHESACCEPTED? IOW, I don't care enough to bother with it myself, but if you provide the patch, I'll take it. Tho I guess WORKSFORME sort of fits, if the definition is bent far enough. -- 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
[gentoo-dev] Re: [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Fabio Erculiani posted on Sun, 02 Sep 2012 16:45:12 +0200 as excerpted: > - If SDEPEND contains USE flags, these are written in stone and cannot > be changed without a rebuild. This is generally fine for source > packages, a bit less for binpkgs, but not really a big deal IMO. This being the case, don't we effectively already have the feature in the form of default-use? Isn't a USE flag defaulted-on in effect ALREADY a "suggestion"? That seems to me to be how it's used in practice. For a new "suggested" mechanism to be actually worth the implementation cost, I'd /suggest/ that it must allow flipping state without a rebuild. Otherwise we effectively already have it in the form of default-use, so what's the point? Now it's certainly possible to argue that once one sets a global USE flag, the visibility of default-use "suggests" isn't particularly high, and that ideally --ask and --pretend with --verbose (and presumably whatever corresponds in the other PMs) should somehow emphasize "suggest" state a bit more than simply "it's there, make your own choice" state, which is arguably what normal use flags are, but that's a PM UI issue, not a lack of ability to mark "suggests" in the ebuild. Unless I'm missing something, the information's already expressible in the ebuild with existing default-use; it just arguable needs a bit more emphasis in the UI /as/ suggests, because that's what default-use in effect already IS. -- 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
