Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
On Fri, Jun 22, 2012 at 3:40 AM, Ciaran McCreesh wrote: > On Thu, 21 Jun 2012 23:01:15 +0200 > Michał Górny wrote: >> Just a short note as it seems some confusion arises lately: >> >> Ciaran McCreesh is not a Gentoo dev and his words don't represent >> the position of Gentoo development team. > > Right. Doesn't that make me more important than you? > > https://lwn.net/Articles/501815/ > > -- > Ciaran McCreesh This thread is totally useless, but that lwn link made my day. Thank you. -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 08:39 +0100, Ciaran McCreesh escribió: > On Thu, 21 Jun 2012 09:25:10 +0200 > Pacho Ramos wrote: > > Then, looks clear to me that the way to get things approved in newer > > EAPIs is not clear enough as looks like a lot of devs (like me) don't > > know them (for example, when things to be added to EAPI need also a > > GLEP and a PMS diff, also the needing to get an implementation for any > > package manager). > > That's very much a judgement call. If a feature is "easy", low impact > and uncontroversial, you can ask for it on IRC, the mailing lists or > bugzilla, and chances are someone will do all the work for you. That cannot be the way of doing things, who is the once deciding a feature is "easy"? Is something like: https://bugs.gentoo.org/show_bug.cgi?id=357561 easy enough? Looks like it's getting so much time to get it done that we are now needing to rely on eclasses and manual removal to handle it. > If it's > a big feature with broad impact requiring lots of changes, you need to > do however much work is necessary such that a) the people working on > PMS understand it well enough to document it, b) developers understand > it well enough to know what it involves for them, c) the Council can > compare and contrast it with other proposals, and d) it can be > implemented. > > The "implement it in a package manager" thing is because of what > happened with REQUIRED_USE. It hadn't been implemented previously, and > as it turns out it has some fairly hefty usability issues. Look for example to multilib stuff, looks like mails explaining the issue and how tommy wants to fix it are not enough (I don't mean only the last thread about this problem, I remember he sending more mails explaining the issue months ago), Tommy is also providing PMS people an implementation... and now you come demanding more and more things. If all requirements would be clear from start, this shouldn't occur and all of us would save a lot of time and problems between us. > > > > > I also don't understand why Gentoo is forced to stick with old > > > > ways of doing things until new EAPI is approved > > > > > > That's not what's going on here. The issue is that there might be > > > one person who understands what "the new way of doing things", but > > > he hasn't told us what he thinks that is. Once we get a proper > > > explanation, getting an EAPI out doesn't take long. > > > > > > > But you must confess that old problems like multilib support, force > > package rebuilding or optional dep support are still pending while > > still needing and, the problem with the way things are discussed now > > is that some day anybody arises the problem again, other one demands > > more things to be provided, a discussion starts, the problem gets > > stalled... one year later the same problem arises again. There is > > clearly a lack of information to the rest of developers about how to > > propose anything to get accepted for next EAPI. > > The reason those are still pending is because no-one knows what the > *problem* is, let alone the solution. Seriously, don't you know what are the problems of current way of handling emul packages? :O > That's not an EAPI issue, it's a > developers saying "I want a flying unicorn!" issue. > > > Then, you accept exherbo is not forced to *only* follow EAPI while you > > force Gentoo and portage to only support features approved in an EAPI? > > I think you have a severe misunderstanding of what the EAPI process is > about here... It's not about forcing anything. The point of the EAPI > process is to allow Gentoo to roll things out without requiring > developers to rewrite all their ebuilds every few months (which > happens on Exherbo, incidentally), and without breaking user systems. > Then, I guess we could have something like GEAPI that would require only agreement between gentoo people (and people wanting to reach a consensus) that would also prevent people from needing to rewrite their ebuilds from time to time? Don't you see this way of handling things, with such and obscure way of getting things accepted for every EAPI is really hurting us? If all of us would want to reach consensus it wouldn't be so problematic but, when some people is simply waiting every proposal (even with implementation and after more tries to get it accepted) to ask them for more and more work and, when anybody ask for help to accomplish that, the same one refuses to help if he is not payed for that, this only causes Gentoo to lack some important features for ages. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió: > On 06/21/12 15:25, Pacho Ramos wrote: > > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: > >> On Thu, 21 Jun 2012 08:08:55 +0200 > >> Pacho Ramos wrote: > >>> Also, if I remember correctly, Tommy asked for this some months ago, > >>> you asked for what he sent some days ago and now you require more and > >>> more work to delay things to be implemented. > >> I still haven't seen a clear description of exactly what should be > >> changed and why. I've also not seen a description of exactly what > >> problem is being solved, nor a discussion of the relative merits of > >> implementing a solution to whatever that problem is. All I've seen is a > >> mess of code that "gets it working" in Portage (which isn't the same as > >> "implements it for Portage") and a big wall of text that contains lots > >> that no-one needs to know and little of what's important. This needs to > >> go through the GLEP process, and it needs a PMS diff. > >> > >> In case you're not aware, the first time Gentoo did multilib, it was > >> done as a series of random changes to Portage that no-one really > >> thought through or understood. As you can see, that didn't work... > >> > > Then, looks clear to me that the way to get things approved in newer > > EAPIs is not clear enough as looks like a lot of devs (like me) don't > > know them (for example, when things to be added to EAPI need also a GLEP > > and a PMS diff, also the needing to get an implementation for any > > package manager). Is this documented in some place? > No, and this is a rather random ad-hoc requirement that hasn't been > specified before. > > All previous EAPI processes went through some debate with dev-portage@ > and the other involved people (mostly pkgcore/ferringb and > paludis/ciaranm), then the proposal got handed to council to vote on, > and if council was happy that proposal was hammered into PMS and the new > EAPI published. Most of the time new features had a crude approximation > of a patch for PMS available so that the documentation updates were done > in a timely manner. > > I have no idea why Ciaran is trying to redefine the process now suddenly > and why people are taking this nonsense seriously. I take it seriously because looks like, effectively, this is blocking things. I remember when I first asked for an "easy" way of trying to allow administrator of Gentoo machines to easily handling all that needed rebuilds after updating: https://bugs.gentoo.org/show_bug.cgi?id=413619 Zac kindly pointed me to original bug: https://bugs.gentoo.org/show_bug.cgi?id=192319 I knew about that bug report but, as it was still pending after years, I thought there were technical issues making it hard to fix and, then, I tried to propose and easier solution at least until best one can be implemented. Then, if you remember the thread I opened here some weeks ago about this issue, you will see how things moved, even when Zac is already working on getting an implementation I am really worried about, even after Zac offering his work and time to get an implementation, when he offers it, Ciaran will reject it with some other excuse :( > > > If not, I think it > > should be documented and, of course, it should be done by PMS team if > > possible as they clearly know what they expect to get for approval if > > needed since, I discussed some days ago, council will simply accept some > > specific features to be included in next eapi once they are accepted by > > PMS team. That way, we could save a lot of time, know what steps are > > pending, try to ask for help for some specific steps and, finally, get > > it discussed in PMS people providing all what is needed. > I would say PMS team accepts what council signs off ... or am I seeing > the order wrong here? > > > So, the normal way to get a feature into the next EAPI is ... write a > specification to the best of your capabilities, present it here, when > people are done bashing it ask PMS people to help you prepare a PMS > patch so that you can suggest it to Council, and then it's mostly a > matter of waiting until the next EAPI is finalized (which currently runs > at a glacial pace of about one EAPI a year as far as I remember) > > > Take care, > > Patrick > > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió: > On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos wrote: > > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: > >> On Thu, 21 Jun 2012 08:08:55 +0200 > >> Pacho Ramos wrote: > >> > Also, if I remember correctly, Tommy asked for this some months ago, > >> > you asked for what he sent some days ago and now you require more and > >> > more work to delay things to be implemented. > >> > >> I still haven't seen a clear description of exactly what should be > >> changed and why. I've also not seen a description of exactly what > >> problem is being solved, nor a discussion of the relative merits of > >> implementing a solution to whatever that problem is. All I've seen is a > >> mess of code that "gets it working" in Portage (which isn't the same as > >> "implements it for Portage") and a big wall of text that contains lots > >> that no-one needs to know and little of what's important. This needs to > >> go through the GLEP process, and it needs a PMS diff. > >> > >> In case you're not aware, the first time Gentoo did multilib, it was > >> done as a series of random changes to Portage that no-one really > >> thought through or understood. As you can see, that didn't work... > >> > > > > Then, looks clear to me that the way to get things approved in newer > > EAPIs is not clear enough as looks like a lot of devs (like me) don't > > know them (for example, when things to be added to EAPI need also a GLEP > > and a PMS diff, also the needing to get an implementation for any > > package manager). Is this documented in some place? If not, I think it > > should be documented and, of course, it should be done by PMS team if > > possible as they clearly know what they expect to get for approval if > > needed since, I discussed some days ago, council will simply accept some > > specific features to be included in next eapi once they are accepted by > > PMS team. That way, we could save a lot of time, know what steps are > > pending, try to ask for help for some specific steps and, finally, get > > it discussed in PMS people providing all what is needed. > > > > > >> > I also don't understand why Gentoo is forced to stick with old ways > >> > of doing things until new EAPI is approved > >> > >> That's not what's going on here. The issue is that there might be one > >> person who understands what "the new way of doing things", but he > >> hasn't told us what he thinks that is. Once we get a proper > >> explanation, getting an EAPI out doesn't take long. > >> > > > > But you must confess that old problems like multilib support, force > > package rebuilding or optional dep support are still pending while still > > needing and, the problem with the way things are discussed now is that > > some day anybody arises the problem again, other one demands more things > > to be provided, a discussion starts, the problem gets stalled... one > > year later the same problem arises again. There is clearly a lack of > > information to the rest of developers about how to propose anything to > > get accepted for next EAPI. > > I'm not following you here. > > 1) Usually features need a reference implementation. > 2) For portage, there are like 3-5 people who know portage well enough > to write that for you. > 3) You generally have to convince them to do it before you can move forward. > 4) Most features never even get a reference implementation. > > There is this vague idea that you can just propose something; get > consensus on the ML, everyone goes to implement it, and then it works > just as designed. That is usually called the 'waterfall' model and its > really hard to do correctly. > > What I imagine the process is: > > 1) Submit an idea to the ML; you just need feedback (not consensus, > which is likely impossible for non-trivial ideas.) > 1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly > required. > 2) Take feedback from step one and make an initial implementation. You > will likely find some assumptions in your 'design' from step one were > wrong, as well as other implementation issues (UI, performance, etc.) > 3) Modify your idea to address the problems in 2. > 4) Modify your implementation to address the problems in 2. > 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems. > 6) Submit a diff to PMS outlining how the package manager behavior is > changed by your feature. This generally needs to be specific enough so > that other package manager authors can implement the feature. > 7) Submit a devmanual patch telling users how to use the feature. > > Most people fail at step two; usually because they try to get > 'consensus' at step one, which is stupid and a waste of time. There > are a few hundred people on this list; we will never all agree, on > basically anything. So take the feedback people give you and do > something with it. > OK thanks :) What I was trying to show is that this process is not clea
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 09:53:37 +0200 Pacho Ramos wrote: > Don't you see this way of handling things, with such and obscure way > of getting things accepted for every EAPI is really hurting us? What is hurting is people demanding features without specifying what the problem is, how it will be solved or what the impact on users or developers will be, and then taking up everyone's time with complaints when they don't get magical flying unicorns instantly. If you want something, you either have to do the work yourself, or find someone to do it. And here's the thing: you're assuming that "the work" is trivial, which for some of the things you're discussing it really isn't. The PMS wording is the trivial bit that comes at the end once the problem and solution have been worked out. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > What is hurting is people demanding features without specifying what > the problem is Part of enabling progress is to show a strong will to communicate, with the goal of extracting common understanding from discussion. In any project based on volunteer effort you must show that you too are interested in giving, for anyone to give you anything. When it's not obvious that you want to receive - to the point where you drive the discussion (the horror!) in order to arrive at that point of common understanding - then people will be upset and look down on you, because dealing with you leaves too sour a taste behind. //Peter pgpMq9Pj6tnx6.pgp Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió: > Ciaran McCreesh wrote: > > What is hurting is people demanding features without specifying what > > the problem is > > Part of enabling progress is to show a strong will to communicate, > with the goal of extracting common understanding from discussion. > > In any project based on volunteer effort you must show that you too > are interested in giving, for anyone to give you anything. > > When it's not obvious that you want to receive - to the point where > you drive the discussion (the horror!) in order to arrive at that > point of common understanding - then people will be upset and look > down on you, because dealing with you leaves too sour a taste behind. > > > //Peter As Peter explains, I think it is now clear enough what I was demanding (about clarifying what is needed to get things in next EAPI to prevent issues like Tommy is suffering to get multilib stuff done), but I star to think Ciaran thinks it's easier to simply wear a blindfold on to keep thinking all what he says cannot be corrected at all, neither improved and others must follow his instructions blindly signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:24 +0200, Pacho Ramos escribió: > El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió: > > Ciaran McCreesh wrote: > > > What is hurting is people demanding features without specifying what > > > the problem is > > > > Part of enabling progress is to show a strong will to communicate, > > with the goal of extracting common understanding from discussion. > > > > In any project based on volunteer effort you must show that you too > > are interested in giving, for anyone to give you anything. > > > > When it's not obvious that you want to receive - to the point where > > you drive the discussion (the horror!) in order to arrive at that > > point of common understanding - then people will be upset and look > > down on you, because dealing with you leaves too sour a taste behind. > > > > > > //Peter > > As Peter explains, I think it is now clear enough what I was demanding > (about clarifying what is needed to get things in next EAPI to prevent > issues like Tommy is suffering to get multilib stuff done), but I star > to think Ciaran thinks it's easier to simply wear a blindfold on to keep > thinking all what he says cannot be corrected at all, neither improved > and others must follow his instructions blindly Ciaran, simply think that, if PMS team agrees with a doc explaining what needs to be provided and the procedure, you will also save time and not need to follow this tedious discussions, all parts will benefit for sure. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 12:24:32 +0200 Pacho Ramos wrote: > As Peter explains, I think it is now clear enough what I was demanding > (about clarifying what is needed to get things in next EAPI to prevent > issues like Tommy is suffering to get multilib stuff done), but I star > to think Ciaran thinks it's easier to simply wear a blindfold on to > keep thinking all what he says cannot be corrected at all, neither > improved and others must follow his instructions blindly Oh come on. You're just shooting the messenger. You don't like being told that if you want something, someone needs to do the work, and you can't just say "I want a flying unicorn!" and expect it to happen. I'm not the only one saying it, either. I point you to this, for example: http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml > Ciaran, simply think that, if PMS team agrees with a doc explaining > what needs to be provided and the procedure, you will also save time > and not need to follow this tedious discussions, all parts will > benefit for sure. The procedure is not the important part. The important part is finding someone who can do enough of the work that the PMS team can understand your proposal and polish off the rough edges. The work that needs to be done for that is very much a case by case thing, and it's not just a simple list of steps that anyone can follow blindly. The features you're asking for that aren't magically appearing are hard. I'll remind you that for "big" features, the GLEP process is already documented. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: My wishlist for EAPI 5
Ciaran McCreesh posted on Sat, 23 Jun 2012 10:38:33 +0100 as excerpted: > On Sat, 23 Jun 2012 09:53:37 +0200 Pacho Ramos wrote: >> Don't you see this way of handling things, with such and obscure way of >> getting things accepted for every EAPI is really hurting us? > > What is hurting is people demanding features without specifying what the > problem is, how it will be solved or what the impact on users or > developers will be, and then taking up everyone's time with complaints > when they don't get magical flying unicorns instantly. > > If you want something, you either have to do the work yourself, or find > someone to do it. And here's the thing: you're assuming that "the work" > is trivial, which for some of the things you're discussing it really > isn't. The PMS wording is the trivial bit that comes at the end once the > problem and solution have been worked out. Without weighing in on either side of the technical details of this debate, it's possible to observe two things: 1) Fact: Unfortunately, your method of argument, Ciaran, doesn't endear you to a number of devs. Some may have the impulse to reject an argument simply because it comes from you. 2) PMS is supposed to be about specifying things well enough that all three PMs can implement compatible ebuild/eclass/etc interpretation and execution. 3) Given the above, it would be of /great/ benefit to your argument if either Zac or Brian (or preferably both) stepped up from time to time and said yes, this is really an issue. Not that they'd necessarily reply to everything you do, but if they could reply once in support, such that you could refer people back to those replies from elsewhere... This would be of particular help concerning the multi-arch work where there's already an implementation for portage, but it is argued a proper spec is still lacking. Obviously if it's approved Brian's going to need to implement it as well as you, and having him too say there's not enough there to do so, ideally with his estimation of where the process is in terms of work needed, as well, would go quite a long way. Similarly but from a different angle, if Zac says that he's not satisfied with the specification even with portage's already implementing what's there and having it proven to work (for whatever definition of "work"), that goes quite a way toward giving the argument for a better spec some serious support, as well. If you can't get those statements, then round and round the discussion will go until people are sick, and until people simply ignore your position and push /something/ thru, which would be a real shame if it could be practically[1] made better, or the practical ideal of PMS ends up getting lost in the results. And if you /can/ get those statements, why are we still going round and round with all this? (Again, references to said statements may be necessary from time to time, given the quantity of posts and the likelihood single answers in support of your position could be missed.) [1] Practically: favorable cost/benefit ratio for the work 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
[gentoo-dev] Re: My wishlist for EAPI 5
Duncan posted on Sat, 23 Jun 2012 10:37:38 + as excerpted: > Ciaran McCreesh posted on Sat, 23 Jun 2012 10:38:33 +0100 as excerpted: > > > 3) Given the above, it would be of /great/ benefit to your argument if > either Zac or Brian (or preferably both) stepped up from time to time > and said yes, this is really an issue. > > Not that they'd necessarily reply to everything you do, but if they > could reply once in support, such that you could refer people back to > those replies from elsewhere... Right after posting that, I saw you mentioned the link below. Thanks. That's exactly the sort of thing I think a lot of readers (myself included) could use a bit more of, reminding us it's not just you. http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml -- 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: My wishlist for EAPI 5
On Sat, 23 Jun 2012 10:37:38 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > 1) Fact: Unfortunately, your method of argument, Ciaran, doesn't > endear you to a number of devs. Some may have the impulse to reject > an argument simply because it comes from you. Perhaps Gentoo should be doing more to correct the attitudes of those developers, then. > 2) PMS is supposed to be about specifying things well enough that all > three PMs can implement compatible ebuild/eclass/etc interpretation > and execution. Not exactly. It's about making sure ebuild developers know what they can rely upon from a package mangler. > 3) Given the above, it would be of /great/ benefit to your argument > if either Zac or Brian (or preferably both) stepped up from time to > time and said yes, this is really an issue. They already have. For example: http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml > And if you /can/ get those statements, why are we still going round > and round with all this? That's a very good question. Why are people still blaming the PMS team for the lack of magical appearance of flying unicorns rather than making their case for the introduction of a horse? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 11:31 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 12:24:32 +0200 > Pacho Ramos wrote: > > As Peter explains, I think it is now clear enough what I was demanding > > (about clarifying what is needed to get things in next EAPI to prevent > > issues like Tommy is suffering to get multilib stuff done), but I star > > to think Ciaran thinks it's easier to simply wear a blindfold on to > > keep thinking all what he says cannot be corrected at all, neither > > improved and others must follow his instructions blindly > > Oh come on. You're just shooting the messenger. You don't like being > told that if you want something, someone needs to do the work, and you > can't just say "I want a flying unicorn!" and expect it to happen. > > I'm not the only one saying it, either. I point you to this, for > example: > > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml That shows how things can be done and how shouldn't be done, it's not casual that you are always involved in this kind of discussions, instead of thinking all people is trying to "shoot the messenger", maybe you should think about you acts here (I know it's difficult, specially when discussions are done virtually and not in real world where you, probably, would understand better that your way of demanding things and putting conditions is not the way to go). Making constructive suggestions instead of others that can be easily interpreted as whims is the way to go. > > > Ciaran, simply think that, if PMS team agrees with a doc explaining > > what needs to be provided and the procedure, you will also save time > > and not need to follow this tedious discussions, all parts will > > benefit for sure. > > The procedure is not the important part. The important part is finding > someone who can do enough of the work that the PMS team can understand > your proposal and polish off the rough edges. The work that needs to be > done for that is very much a case by case thing, and it's not just a > simple list of steps that anyone can follow blindly. The features > you're asking for that aren't magically appearing are hard. > > I'll remind you that for "big" features, the GLEP process is already > documented. > You know what I exactly mean, don't try to change the topic to "GLEP process is already documented" to hide you don't want to put anything of your time to help others to get proper documentation prepared to show to pms team. Of course, you have the right to do so as this is all contribution work that we do it if we want and have time, but don't try to hide it in this way. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: My wishlist for EAPI 5
On Sat, Jun 23, 2012 at 6:44 AM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 10:37:38 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> 1) Fact: Unfortunately, your method of argument, Ciaran, doesn't >> endear you to a number of devs. Some may have the impulse to reject >> an argument simply because it comes from you. > > Perhaps Gentoo should be doing more to correct the attitudes of those > developers, then. > This is an impression that many people get, unfortunately. You can't fix it by beating people up. There are those who speak up from time to time attempting to moderate, although to some extent this is noise in what should be a technical discussion. > >> And if you /can/ get those statements, why are we still going round >> and round with all this? > > That's a very good question. Why are people still blaming the PMS team > for the lack of magical appearance of flying unicorns rather than > making their case for the introduction of a horse? > Perhaps what is being missed is that THIS ISN'T A WATERFALL METHODOLOGY!!! PMS is intended to be semi-retrospective - it is developed in parallel with the features it documents. It is intended to preserve standards, to be something to refer to before finalizing PM code, and to guide ebuild writers. It isn't intended to be a conceptual requirements/design spec to be included in the RFP for the coding team in India. So, the requirement is a reference implementation in one of the PMs. So, the question of "who gets to decide it is easy" is simple - whoever writes and releases the patch gets to decide. That can be you if you write a full PM that handles all the existing EAPIs plus whatever is new, or demonstrate some kind of commitment to maintaining a fork. Face it, there are only a handful of devs here doing PM work, portage or otherwise. I can post all day on the list about how Gentoo OUGHT to be able to do foo. I can post all day about how Gentoo NEEDS to do foo and how it is downright obvious how not doing foo ruins the reputation of Gentoo and is going to kill us in six months. None of this is going to do anything unless I can convince/bribe/cajole one of the devs working on a PM to implement foo, or, heaven-forbid, write it myself. Somebody asked earlier why Cirian is running the whole PMS process and why Gentoo can't have its own GEAPI that will be peaceful and harmonious. My answers to that are twofold: 1. While perhaps a different leader might give people a warmer feeling about it, I think many of these issues are just inherent to the nature of the problem - PM features don't write themselves. Others might disagree, and that is fine. 2. I don't see anybody else stepping up. PMS is in git, so just clone the thing and if you can convince some PM devs to follow you there is no reason that a Gentoo dev couldn't take it over. I suspect that many would like to see this happen. However, to be honest I think that warm-and-fuzzies aside Cirian has actually done a fairly good job with it as he is pretty passionate about PM specs. This is a big commitment, and what isn't needed is somebody who is going to step in to get their favorite feature in there and then let it die. As far as helping others to create pms paperwork goes, there is no reason this has to fall exclusively on Cirian. The fact that nobody else is stepping up to help those who are new just reflects the nature of something like this - FOSS projects tend to be weak on specs. Bottom line - do I think Cirian might get himself further in life if he deals with others a bit differently? Sure. Do I think that this is the main thing keeping us outside of the golden land of PMS? Not really. Rich
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:05:51 +0200 Pacho Ramos wrote: > > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml > > That shows how things can be done and how shouldn't be done, it's not > casual that you are always involved in this kind of discussions, Yes, because I'm prepared to put in the work to make sure these things get done properly, whereas others will just comment once and then ignore the rest of the thread. > instead of thinking all people is trying to "shoot the messenger", > maybe you should think about you acts here (I know it's difficult, > specially when discussions are done virtually and not in real world > where you, probably, would understand better that your way of > demanding things and putting conditions is not the way to go). Making > constructive suggestions instead of others that can be easily > interpreted as whims is the way to go. Uh huh, and that's what I've been doing the whole time when I've been asking for a patch for PMS, a GLEP etc. > > I'll remind you that for "big" features, the GLEP process is already > > documented. > > You know what I exactly mean, don't try to change the topic to "GLEP > process is already documented" to hide you don't want to put anything > of your time to help others to get proper documentation prepared to > show to pms team. Of course, you have the right to do so as this is > all contribution work that we do it if we want and have time, but > don't try to hide it in this way. That's nonsense. I've put in a lot of work on the PMS side for features that I understand. If multilib gets beyond what Brian called "a fairly opaque list of things", *then* I'm quite happy to help if I'm able. Right now, though, there's nowhere near enough that I (or as far as I can see, anyone else) can even start to go anywhere with it. This isn't going nowhere because no-one wants to help. It's going nowhere because what's been presented so far is nowhere near enough that anyone *can* help, and requests for a better description of what we're supposed to be looking at are being met with complaints that we haven't magically done all of the remaining work (which on this one I suspect is far more effort than what's been done so far). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > > Making constructive suggestions instead of others that can be > > easily interpreted as whims is the way to go. > > Uh huh, and that's what I've been doing the whole time when I've > been asking for a patch for PMS, a GLEP etc. .. > requests for a better description we're supposed to be looking at No, this isn't really constructive. As I wrote, try to drive the discussion by adding substance to it, rather than fueling flames by requesting others to refine. Since it is an area where you may be able to contribute, I think it would be great if you did! > are being met with complaints that we haven't magically done all > of the remaining work I think you're right that complaints are about your response, but I absolutely do not interpret the complaints to be that you personally or the PMS team did not implement the requested feature. I think that's a misunderstanding of yours. If you don't understand something of what thus far has been written, then why not ask specific questions to fill those gaps, and move on? //Peter pgpnKg4TULJ2m.pgp Description: PGP signature
[gentoo-dev] ewarn and package upgrades
On Sat, Jun 23, 2012 at 7:32 AM, wrote: > WARN: postinst > Please rebuild both libxcb and xcb-util if you are upgrading from version 1.6 > I've read enough warnings like this (many packages use them) that it occurred to me that perhaps there should be some better way of dealing with this. I realize we have a huge discussion going on about suggested depends and such which could resolve it long-term. If that really doesn't work out, then perhaps at least it would be useful if it were obvious in ELOG messages what the old and new version were, or some other stopgap measure. Bonus points if the ebuild can figure it out and only generate the warning conditionally, but I'd be happy if I could just delete the message without having to figure out what version I was previously running... Rich
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:38:09 +0200 Peter Stuge wrote: > If you don't understand something of what thus far has been written, > then why not ask specific questions to fill those gaps, and move on? The multilib material isn't at the point where specific questions can be asked. Brian's description of it as an "opaque list of things" is pretty much spot on. That's why we want a GLEP and a PMS diff -- an attempt at those might bring this to the point where we can say something other than "huh?". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
Ciaran McCreesh wrote: > bring this to the point where we can say something other than "huh?". You can accelerate by making one guess about each thing on the list and asking for confirmation of your guess. It sounds silly, but I realized that this actually happens all the time offline - at least to me. I interpret, ask if I got it right, then move on. It's pretty efficient, but requires both sender and receiver wanting successful transmission. //Peter pgpTOeGyILj4n.pgp Description: PGP signature
Re: [gentoo-dev] ewarn and package upgrades
On Sat, 23 Jun 2012 07:40:02 -0400 Rich Freeman wrote: > On Sat, Jun 23, 2012 at 7:32 AM, wrote: > > WARN: postinst > > Please rebuild both libxcb and xcb-util if you are upgrading from > > version 1.6 > > > > I've read enough warnings like this (many packages use them) that it > occurred to me that perhaps there should be some better way of dealing > with this. > > I realize we have a huge discussion going on about suggested depends > and such which could resolve it long-term. If that really doesn't > work out, then perhaps at least it would be useful if it were obvious > in ELOG messages what the old and new version were, or some other > stopgap measure. Bonus points if the ebuild can figure it out and > only generate the warning conditionally, but I'd be happy if I could > just delete the message without having to figure out what version I > was previously running... > > Rich > REPLACING_VERSIONS and REPLACED_BY_VERSION added in EAPI 4 can be used to do this things with elog messages.
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 13:52:24 +0200 Peter Stuge wrote: > Ciaran McCreesh wrote: > > bring this to the point where we can say something other than > > "huh?". > > You can accelerate by making one guess about each thing on the list > and asking for confirmation of your guess. > > It sounds silly, but I realized that this actually happens all the > time offline - at least to me. I interpret, ask if I got it right, > then move on. It's pretty efficient, but requires both sender and > receiver wanting successful transmission. The issue is not that we don't understand the list. The issue is that we don't understand the problem (beyond superficially), how the proposed solution works from an ebuild perspective, whether the solution solves the problem, or how it all fits together. Most of the stuff on the list is irrelevant from a design perspective. It's not that the list is hard to understand, it's that understanding the problem and solution requires completely different material. To take one example, figuring out exactly which variables get mangled is an unimportant detail at this stage (and likely we'll want to offload it to profiles, not hard-code it in PMS) and not a central part of the proposal. What we need is a GLEP, describing it in high level terms with a discussion upon how it impacts users and ebuild developers, and a PMS patch, highlighting what's to be changed in specific technical terms. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:37 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 13:38:09 +0200 > Peter Stuge wrote: > > If you don't understand something of what thus far has been written, > > then why not ask specific questions to fill those gaps, and move on? > > The multilib material isn't at the point where specific questions can be > asked. Brian's description of it as an "opaque list of things" is > pretty much spot on. That's why we want a GLEP and a PMS diff -- an > attempt at those might bring this to the point where we can say > something other than "huh?". > Looks like you have now opted to use Brian's comment as a kind of "shield" of similar and discuss only about multilib, even when this thread was more general and we were talking to the problems shown in recent discussions (from forcing rebuilds issue, optional deps problems to some trivial questions like know where we can see what things are being worked out for eapi5). In all that discussions there were a clear tendency to always say "it's fine the way it's", even when a lot of people didn't even know what things were going to be included in eapi5, or discuss for days about the forcing rebuilds issue (with the, now classical, glib vs dbus-glib/g-i issue) to finally still tell people "we still didn't fully know what the problem was". I remember that, just after Brian and Zac's comments about trying to clarify things a bit on that thread and reach a solution, your reply to them was that we were missing a brilliant opportunity to "encourage developers put in a bit more work to save users a huge amount of pain here". Personally, I see a clear difference about their way to show their disagreement and yours. Of course, I know how this thread will end: once we decide to stop replying (or anybody asks us to stop) as you seem to find this happy or so and, of course, you will always say the last word, the problem will get stalled until three months later somebody else rises the problem again letting you to show again that "always rejecting position" you seem to like. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 12:59 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 13:52:24 +0200 > Peter Stuge wrote: > > Ciaran McCreesh wrote: > > > bring this to the point where we can say something other than > > > "huh?". > > > > You can accelerate by making one guess about each thing on the list > > and asking for confirmation of your guess. > > > > It sounds silly, but I realized that this actually happens all the > > time offline - at least to me. I interpret, ask if I got it right, > > then move on. It's pretty efficient, but requires both sender and > > receiver wanting successful transmission. > > The issue is not that we don't understand the list. The issue is that > we don't understand the problem (beyond superficially), how the > proposed solution works from an ebuild perspective, whether the > solution solves the problem, or how it all fits together. Most of the > stuff on the list is irrelevant from a design perspective. It's not > that the list is hard to understand, it's that understanding the > problem and solution requires completely different material. > > To take one example, figuring out exactly which variables get mangled > is an unimportant detail at this stage (and likely we'll want to > offload it to profiles, not hard-code it in PMS) and not a central part > of the proposal. > > What we need is a GLEP, describing it in high level terms with a > discussion upon how it impacts users and ebuild developers, and a PMS > patch, highlighting what's to be changed in specific technical terms. > What we *also* need is to document this requirements to let people present that work directly instead of losing days figuring out what is needed or what not signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 14:11:28 +0200 Pacho Ramos wrote: > Looks like you have now opted to use Brian's comment as a kind of > "shield" of similar and discuss only about multilib, even when this > thread was more general and we were talking to the problems shown in > recent discussions (from forcing rebuilds issue, optional deps > problems to some trivial questions like know where we can see what > things are being worked out for eapi5). For optional deps, we're close to having two proposals. That's moving forwards. Whether or not it will be in EAPI 5 depends solely upon timing, and whether the Council ends up liking at least one of the two proposals. For "forced rebuilds", there's a proposal already, and Zac has just done implementation work, and most of the PMS patch was written ages ago for kdebuild-1 and the original EAPI 3. So again, whether or not that ends up in EAPI 5 is just a matter of timing and Council approval. For "what's being worked on", you just need to look at the PMS list. So I'm really not sure what your problem is there... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
On Sat, 23 Jun 2012 14:16:13 +0200 Pacho Ramos wrote: > What we *also* need is to document this requirements to let people > present that work directly instead of losing days figuring out what is > needed or what not The requirement is that the PMS team needs to be able to understand the proposal, and that someone needs to do however much work is necessary (which varies massively from proposal to proposal -- multilib is at least a thousand times more complicated than adding a new function that outputs stuff based upon a use flag) to be able to present it in a form acceptable to the Council. That's all there is to it. There is no lengthy form P123b.5 to fill in or anything like that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] My wishlist for EAPI 5
El sáb, 23-06-2012 a las 13:16 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 14:11:28 +0200 > Pacho Ramos wrote: > > Looks like you have now opted to use Brian's comment as a kind of > > "shield" of similar and discuss only about multilib, even when this > > thread was more general and we were talking to the problems shown in > > recent discussions (from forcing rebuilds issue, optional deps > > problems to some trivial questions like know where we can see what > > things are being worked out for eapi5). > > For optional deps, we're close to having two proposals. That's moving > forwards. Whether or not it will be in EAPI 5 depends solely upon > timing, and whether the Council ends up liking at least one of the two > proposals. > > For "forced rebuilds", there's a proposal already, and Zac has just > done implementation work, and most of the PMS patch was written ages > ago for kdebuild-1 and the original EAPI 3. So again, whether or not > that ends up in EAPI 5 is just a matter of timing and Council approval. > > For "what's being worked on", you just need to look at the PMS list. > > So I'm really not sure what your problem is there... > Your cynicism, that is the problem I see signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
Le dimanche 10 juin 2012 à 21:55 +0200, Sebastian Pipping a écrit : > On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote: > > For libraries, if possible, try splitting gtk2 and gtk3 support into > > different slots (see net-libs/webkit-gtk for an example; the gtk2-based > > versions have -r2xx revision numbers and go in slot 2, while the > > gtk3-based versions have -r3xx revision numbers and go in slot 3). > > That's a crazy but interesting approach. That's not crazy, it's the least confusing way to go as package managers cannot have the same version in two slots. We added a suffix that allows differenciation and still easy reading of which slot the upgrade is about. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 14:53:47 +0200 Gilles Dartiguelongue wrote: > Le dimanche 10 juin 2012 à 21:55 +0200, Sebastian Pipping a écrit : > > On 06/10/2012 05:54 AM, Alexandre Rostovtsev wrote: > > > For libraries, if possible, try splitting gtk2 and gtk3 support > > > into different slots (see net-libs/webkit-gtk for an example; the > > > gtk2-based versions have -r2xx revision numbers and go in slot 2, > > > while the gtk3-based versions have -r3xx revision numbers and go > > > in slot 3). > > > > That's a crazy but interesting approach. > > That's not crazy, it's the least confusing way to go as package > managers cannot have the same version in two slots. We added a suffix > that allows differenciation and still easy reading of which slot the > upgrade is about. Perhaps you should be asking for a feature that allows you to solve it properly, rather than abusing existing features to do something they're not intended for. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
Le lundi 11 juin 2012 à 19:48 +0100, Ciaran McCreesh a écrit : > On Mon, 11 Jun 2012 20:41:37 +0200 > Pacho Ramos wrote: > > > No, your goal is to provide a distribution. Gentoo has repeatedly > > > shot itself in the foot, leg, groin etc by favouring short-term > > > hacks over a well thought out, validated, self-enforcing design. > > > Right now nearly all of the package manager work is on paying off > > > previously incurred technical debt, and in the mean time you're > > > busy adding to it. > > > > The problem here is that we (or, at least, I) are a bit unsure about > > how this could be handled better and, then, try to use that better > > way in the future. If you (or any) have some suggestion, it would be > > nice :) > > It is handled better by working out what exactly the problem is, and if > you can't implement it nicely using existing features, then not > implementing it at all until you have suitable features. > Sorry to make this old thread pop up again but, no, it is not acceptable to not ship packages like webkit just because you dislike the solution we used to workaround a well known problem in ebuild packaging. FTR, this solution may have problems, that you are free to highlight, but it is has been carefully thought out to not be too much of a burden for devs and users alike. When someone comes up with a solution that is accepted for PMS, we will be more than happy to switch to it. So please stop complaining and do what you are best known for, find a solution that can fit PMS. TIA. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 15:02:41 +0200 Gilles Dartiguelongue wrote: > > It is handled better by working out what exactly the problem is, > > and if you can't implement it nicely using existing features, then > > not implementing it at all until you have suitable features. > > Sorry to make this old thread pop up again but, no, it is not > acceptable to not ship packages like webkit just because you dislike > the solution we used to workaround a well known problem in ebuild > packaging. No-one is saying "don't ship webkit". What is being asked is that a) you ship webkit with a subset of functionality disabled if necessary for now, and b) that you provide a general description of what you can't provide cleanly using existing functionality. If you really think it's necessary to come up with a workaround like this, though, then you should be mailing the list and asking for QA or Council approval, rather than doing it and then asking for forgiveness later. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFC: PROPERTIES=funky-slots
There's been a move towards using slots for "clever" things that don't fit the traditional way of how slots worked. Examples include the new gtk2 / gtk3 handling and Ruby gems virtuals. Aside from being abusive, this screws things up for Paludis users. Paludis tends to bring in newer versions when possible (so that users aren't stuck with an old GCC forever), and allows the user to select when new slots are brought in. When suddenly a few packages are using slots and versions to "mean" something other than what they used to, this makes the feature unusable. Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES value called "funky-slots", which should be set on every version of any package that uses slots in an unconventional manner. This probably doesn't need EAPI control, since package manglers are free to ignore PROPERTIES tokens. It won't solve the abuse, but it will allow the impact upon users to be lessened. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
Le samedi 23 juin 2012 à 14:08 +0100, Ciaran McCreesh a écrit :
> On Sat, 23 Jun 2012 15:02:41 +0200
> Gilles Dartiguelongue wrote:
> > > It is handled better by working out what exactly the problem is,
> > > and if you can't implement it nicely using existing features, then
> > > not implementing it at all until you have suitable features.
> >
> > Sorry to make this old thread pop up again but, no, it is not
> > acceptable to not ship packages like webkit just because you dislike
> > the solution we used to workaround a well known problem in ebuild
> > packaging.
>
> No-one is saying "don't ship webkit". What is being asked is that a) you
> ship webkit with a subset of functionality disabled if necessary for
> now, and b) that you provide a general description of what you can't
> provide cleanly using existing functionality.
Well the problem is simple, we need to ship webkit with gtk2 and gtk3
support. This is needed because gentoo has gtk2 based desktop/apps and
because we want to ship gnome3 for example.
Cool thing is that webkit supports being built with each toolkit without
conflicting with the build from the other toolkit hence we ended up
using SLOTS.
Then the problem is that you cannot have two ebuilds of the same version
in two different slots.
We then had a couple of solutions, most notable being:
* using -r${SLOT}${PATCHLEVEL} suffix, being a strictly increasing
number that is not expected to go over 300 which is the start of the
sequence for the other slot.
* using a new package name, duplicating ebuilds
> If you really think it's necessary to come up with a workaround like
> this, though, then you should be mailing the list and asking for QA or
> Council approval, rather than doing it and then asking for forgiveness
> later.
As far as I remember the subject was discussed (at least) once on this
mailing list before the problem even occurred for gtk2/gtk3 handling and
everyone was ok with it.
Shall we add that subject to next council meeting or do we just wait for
QA's opinion here ?
--
Gilles Dartiguelongue
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
Forgot to mention that, at least for webkit, this is really a case for slots usage as this is the same software, built for another toolkit. This applies to a couple other ebuilds in this gtk2/gtk3 discussion, but admittedly not all of them. We have at least three cases that Alexandre summed up: * packages shipping gtk based libs only * packages shipping gtk based libs and other libs (gtk-vnc for example) * packages shipping gtk based libs and gtk or non-gtk utilities Some packages most likely should be split, like avahi, but it is not always in the interest of everyone as it makes things much harder to maintain. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 15:33:47 +0200 Gilles Dartiguelongue wrote: > Well the problem is simple, we need to ship webkit with gtk2 and gtk3 > support. This is needed because gentoo has gtk2 based desktop/apps and > because we want to ship gnome3 for example. > > Cool thing is that webkit supports being built with each toolkit > without conflicting with the build from the other toolkit hence we > ended up using SLOTS. You could just have gtk2 and gtk3 use flags in the ebuild, use REQUIRED_USE to ensure that at least one is enabled, and build things twice in the ebuild if necessary. Yes, your ebuild will probably be fairly ugly. This won't be visible to users, though. Users will have to rebuild a version unnecessarily if they want to go from having just gtk2 to gtk2 and gtk3 (or so on). That should be rare enough, compared to frequency of bumps etc, that it's not a severe enough problem to warrant a hack until a nice alternative is available. > Shall we add that subject to next council meeting or do we just wait > for QA's opinion here ? I'd like to know why using USE flags until a nicer solution is available is sufficiently terrible that it warrants a hackaround. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh wrote: > There's been a move towards using slots for "clever" things that don't > fit the traditional way of how slots worked. Examples include the new > gtk2 / gtk3 handling and Ruby gems virtuals. > > Aside from being abusive, this screws things up for Paludis users. > Paludis tends to bring in newer versions when possible (so that users > aren't stuck with an old GCC forever), and allows the user to select > when new slots are brought in. When suddenly a few packages are using > slots and versions to "mean" something other than what they used to, > this makes the feature unusable. > > Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES > value called "funky-slots", which should be set on every version of any > package that uses slots in an unconventional manner. This probably > doesn't need EAPI control, since package manglers are free to ignore > PROPERTIES tokens. It won't solve the abuse, but it will allow the > impact upon users to be lessened. > > -- > Ciaran McCreesh I don't quite understand why this would be necessary. Would "funky-slots" just be used in situations where ebuilds with the same PV but different PVR have different slots? Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only used in libraries; applications use slot deps to select which one they need. Paludis should not remove the -r200 version if it is still referenced in the depgraph, correct?
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 10:02 AM, Mike Gilbert wrote: > On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh > wrote: >> There's been a move towards using slots for "clever" things that don't >> fit the traditional way of how slots worked. Examples include the new >> gtk2 / gtk3 handling and Ruby gems virtuals. >> >> Aside from being abusive, this screws things up for Paludis users. >> Paludis tends to bring in newer versions when possible (so that users >> aren't stuck with an old GCC forever), and allows the user to select >> when new slots are brought in. When suddenly a few packages are using >> slots and versions to "mean" something other than what they used to, >> this makes the feature unusable. >> >> Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES >> value called "funky-slots", which should be set on every version of any >> package that uses slots in an unconventional manner. This probably >> doesn't need EAPI control, since package manglers are free to ignore >> PROPERTIES tokens. It won't solve the abuse, but it will allow the >> impact upon users to be lessened. >> >> -- >> Ciaran McCreesh > > I don't quite understand why this would be necessary. > > Would "funky-slots" just be used in situations where ebuilds with the > same PV but different PVR have different slots? > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only > used in libraries; applications use slot deps to select which one they > need. Paludis should not remove the -r200 version if it is still > referenced in the depgraph, correct? Or maybe you are saying that Paludis will not automatically install a new slot for a package that is already installed, even when referenced by a slot dep?
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 10:06:58 -0400 Mike Gilbert wrote: > > I don't quite understand why this would be necessary. > > > > Would "funky-slots" just be used in situations where ebuilds with > > the same PV but different PVR have different slots? > > > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only > > used in libraries; applications use slot deps to select which one > > they need. Paludis should not remove the -r200 version if it is > > still referenced in the depgraph, correct? > > Or maybe you are saying that Paludis will not automatically install a > new slot for a package that is already installed, even when referenced > by a slot dep? The 'standard' behaviour (which can be changed by the user) for Paludis when doing "complete" resolutions is that whenever there's a slot of something installed, it will try to bring in the newest version of that package, even if it's in a different slot. This is generally a good thing, since newer versions are supposed to be better than older versions. The problem is that now "newer" versions are being used to mean "with a different Ruby implementation" or "built in a different way", which screws up the meaning. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On L, 2012-06-23 at 15:10 +0100, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 10:06:58 -0400 > Mike Gilbert wrote: > > > I don't quite understand why this would be necessary. > > > > > > Would "funky-slots" just be used in situations where ebuilds with > > > the same PV but different PVR have different slots? > > > > > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only > > > used in libraries; applications use slot deps to select which one > > > they need. Paludis should not remove the -r200 version if it is > > > still referenced in the depgraph, correct? > > > > Or maybe you are saying that Paludis will not automatically install a > > new slot for a package that is already installed, even when referenced > > by a slot dep? > > The 'standard' behaviour (which can be changed by the user) for Paludis > when doing "complete" resolutions is that whenever there's a slot of > something installed, it will try to bring in the newest version of that > package, even if it's in a different slot. This is generally a good > thing, since newer versions are supposed to be better than older > versions. The problem is that now "newer" versions are being used to > mean "with a different Ruby implementation" or "built in a different > way", which screws up the meaning. Don't do that if the slotted package in question is not in the @world, and all packages depending on it strictly require the older SLOT.
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit : > > I'd like to know why using USE flags until a nicer solution is > available > is sufficiently terrible that it warrants a hackaround. remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes" hence the guidelines already exposed back when we introduced gtk3 to the tree. As you may have noticed, this is still the solution applied for things hard to split or slot like gtk-vnc or avahi but we didn't see the need to have such USE flags when the library was so easily slottable. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 15:10:01 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 10:06:58 -0400 > Mike Gilbert wrote: > > > I don't quite understand why this would be necessary. > > > > > > Would "funky-slots" just be used in situations where ebuilds with > > > the same PV but different PVR have different slots? > > > > > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is > > > only used in libraries; applications use slot deps to select > > > which one they need. Paludis should not remove the -r200 version > > > if it is still referenced in the depgraph, correct? > > > > Or maybe you are saying that Paludis will not automatically install > > a new slot for a package that is already installed, even when > > referenced by a slot dep? > > The 'standard' behaviour (which can be changed by the user) for > Paludis when doing "complete" resolutions is that whenever there's a > slot of something installed, it will try to bring in the newest > version of that package, even if it's in a different slot. This is > generally a good thing, since newer versions are supposed to be > better than older versions. The problem is that now "newer" versions > are being used to mean "with a different Ruby implementation" or > "built in a different way", which screws up the meaning. I think you should start by describing the problem so we all could understand it, and then we can start thinking about a solution. Is it that Paludis installs a newer SLOT even if a reverse dependency explicitly requests another SLOT? Sounds like a bug to me. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sun, 10 Jun 2012 21:19:19 +0100 Ciaran McCreesh wrote: > On Sat, 09 Jun 2012 23:54:21 -0400 > Alexandre Rostovtsev wrote: > > For libraries, if possible, try splitting gtk2 and gtk3 support into > > different slots (see net-libs/webkit-gtk for an example; the > > gtk2-based versions have -r2xx revision numbers and go in slot 2, > > while the gtk3-based versions have -r3xx revision numbers and go in > > slot 3). > > That is not what revisions are for. If you can't solve a problem > properly using existing mechanisms, ask for new ones. Indeed. But reusing revisions is probably saner than abusing the version number to achieve the same goal. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 17:51:01 +0200 Michał Górny wrote: > I think you should start by describing the problem so we all could > understand it, and then we can start thinking about a solution. It's simple: abusing versions and slots invalidates what is otherwise sensible logic. Thus in the long term we need to stop abusing versions and slots, and in the short term a mechanism is needed to indicate where this abuse happens. This is the short term fix. > Is it that Paludis installs a newer SLOT even if a reverse dependency > explicitly requests another SLOT? Sounds like a bug to me. No, it's that if a user requests a "complete" resolution, Paludis installs the newest version of things that it can. Extensive consultation with users has shown that this is a good behaviour, except in the small number of situations that have recently arisen where people are doing weird things with versions and slots. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 15:21, Ciaran McCreesh wrote: > There's been a move towards using slots for "clever" things that don't > fit the traditional way of how slots worked. Examples include the new > gtk2 / gtk3 handling and Ruby gems virtuals. > > Aside from being abusive, this screws things up for Paludis users. > Paludis tends to bring in newer versions when possible (so that users > aren't stuck with an old GCC forever), and allows the user to select > when new slots are brought in. When suddenly a few packages are using > slots and versions to "mean" something other than what they used to, > this makes the feature unusable. > > Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES > value called "funky-slots", which should be set on every version of any > package that uses slots in an unconventional manner. This probably > doesn't need EAPI control, since package manglers are free to ignore > PROPERTIES tokens. It won't solve the abuse, but it will allow the > impact upon users to be lessened. > Did you read what you wrote and thought about what you request from others? Probably you better should. I can't see any good and more importantly, sufficient description of the problem. There is some vague hint, that paludis is not able to solve dependency chains correctly, but this is something I might got wrong from your mail. An example: "...slots and versions to "mean" something other than what they used to,..." is completely useless without a description of what SLOTS are about and how the should be used. And what is the wrong usage you can find; examples are necessary here for understanding. And your approach (a workaround called "funky-slots") to tackle this what-ever-the-problem-really is, doesn't fit to anything you want from others. To me, it doesn't solve the root cause, but actually I can't judge this, because I am missing a description of what is really going wrong. Don't behave in a way, which you disallow for others. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 16:45:09 +0200 Gilles Dartiguelongue wrote: > Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit : > > I'd like to know why using USE flags until a nicer solution is > > available > > is sufficiently terrible that it warrants a hackaround. > > remember qt3/qt4, gtk/gtk2. We want to avoid repeating these > "mistakes" hence the guidelines already exposed back when we > introduced gtk3 to the tree. We didn't have REQUIRED_USE or use dependencies back then. We do now. > As you may have noticed, this is still the solution applied for things > hard to split or slot like gtk-vnc or avahi but we didn't see the need > to have such USE flags when the library was so easily slottable. Again, REQUIRED_USE. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 17:20:23 +0300 Mart Raudsepp wrote: > > The 'standard' behaviour (which can be changed by the user) for > > Paludis when doing "complete" resolutions is that whenever there's > > a slot of something installed, it will try to bring in the newest > > version of that package, even if it's in a different slot. This is > > generally a good thing, since newer versions are supposed to be > > better than older versions. The problem is that now "newer" > > versions are being used to mean "with a different Ruby > > implementation" or "built in a different way", which screws up the > > meaning. > > Don't do that if the slotted package in question is not in the @world, > and all packages depending on it strictly require the older SLOT. That is an option Paludis provides for users, but doing so leads to old versions of things lying around when an upgrade is preferred. It's also incorrect behaviour when multiple slots are capable of satisfying a dependency. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 18:13:23 +0200 Justin wrote: > Did you read what you wrote and thought about what you request from > others? Probably you better should. Uh huh, and I think we all know there's a huge difference between knowing what versions and slots are and knowing what "a multilib" is. > An example: > > "...slots and versions to "mean" something other than what they used > to,..." > > is completely useless without a description of what SLOTS are about > and how the should be used. And what is the wrong usage you can find; > examples are necessary here for understanding. That's covered in the devmanual and in the user documentation, so there's no need to repeat it here. > To me, it doesn't solve the root cause, but actually I can't judge > this, because I am missing a description of what is really going > wrong. As I've already said, this isn't about solving the root cause. It's about reducing the impact of damage that's already been done until the root cause is solved properly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 06/23/12 21:21, Ciaran McCreesh wrote: > There's been a move towards using slots for "clever" things that don't > fit the traditional way of how slots worked. Examples include the new > gtk2 / gtk3 handling and Ruby gems virtuals. > > Aside from being abusive, No, it solves a real problem. > this screws things up for Paludis users. -EDONTCARE, use a supported package manager > Paludis tends to bring in newer versions when possible (so that users > aren't stuck with an old GCC forever), and allows the user to select > when new slots are brought in. When suddenly a few packages are using > slots and versions to "mean" something other than what they used to, > this makes the feature unusable. > > Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES > value called "funky-slots", which should be set on every version of any > package that uses slots in an unconventional manner. This probably > doesn't need EAPI control, since package manglers are free to ignore > PROPERTIES tokens. It won't solve the abuse, but it will allow the > impact upon users to be lessened. > Hackfix. Hardcode those packages in paludis if you need to. Cleaner and faster quick workaround until you can figure out a clean solution. No reason to hack a working solution to bits, especially as it is rather easy to mask specific versions if they annoy you (as I do to keep my systems gtk3-free). The current solution is a side-effect of some upstreams being very confused, but I like the -r200/-r300 versioning fix for gtk apps.
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 18:17, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 18:13:23 +0200 > Justin wrote: >> Did you read what you wrote and thought about what you request from >> others? Probably you better should. > > Uh huh, and I think we all know there's a huge difference between > knowing what versions and slots are and knowing what "a multilib" is. > Might be right, but that doesn't allow you to break your own rules. Plus I still don't get the problem of using SLOTS in the way they are used now. And I can't find this out by simply googling. In contrast, an explanation of multilib in context of linux distribution and more specific gentoo can be found easily. But that's nothing I wanted to discuss here. Stop acting in this arrogant way you are doing right now. This doesn't make sympathetic in any way and heavily overshadows the technically skills you will have for sure. >> An example: >> >> "...slots and versions to "mean" something other than what they used >> to,..." >> >> is completely useless without a description of what SLOTS are about >> and how the should be used. And what is the wrong usage you can find; >> examples are necessary here for understanding. > > That's covered in the devmanual and in the user documentation, so > there's no need to repeat it here. Ever heard about references. They are good, if you don't like to repeat what is written, but which are necessary context to understand what you are writing. You should use them for the sake of understanding, if you are to lazy to write it out again. > >> To me, it doesn't solve the root cause, but actually I can't judge >> this, because I am missing a description of what is really going >> wrong. > > As I've already said, this isn't about solving the root cause. It's > about reducing the impact of damage that's already been done until the > root cause is solved properly. > My clear vote is No. We shouldn't implement anything which allows bad coding anywhere, just for the sake of having it "solved" now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 18:47:26 +0200 Justin wrote: > On 23.06.2012 18:17, Ciaran McCreesh wrote: > > On Sat, 23 Jun 2012 18:13:23 +0200 > > Justin wrote: > >> Did you read what you wrote and thought about what you request from > >> others? Probably you better should. > > > > Uh huh, and I think we all know there's a huge difference between > > knowing what versions and slots are and knowing what "a multilib" > > is. > > > > Might be right, but that doesn't allow you to break your own rules. > Plus I still don't get the problem of using SLOTS in the way they are > used now. "My own rules" are that enough material is presented that the relevant people understand it. If you look at simple proposals like usex, silent rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for very little in the way of text in cases where the change is easily understood. > And I can't find this out by simply googling. In contrast, an > explanation of multilib in context of linux distribution and more > specific gentoo can be found easily. Oh really? I was under the impression that there wasn't even general agreement upon whether or not multilib applied to "C" or to "C, and Python, and things like it". > Stop acting in this arrogant way you are doing right now. Come on. Submitting a simple proposal with at least as much detail as was provided for other, equally simple proposals is "arrogant" now? > > That's covered in the devmanual and in the user documentation, so > > there's no need to repeat it here. > > Ever heard about references. They are good, if you don't like to > repeat what is written, but which are necessary context to understand > what you are writing. You should use them for the sake of > understanding, if you are to lazy to write it out again. Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where it references what "phase functions" are, or the proposal for usex and say where it references what "use flags" are, or the proposal for silent rules where it references what "econf" is. > >> To me, it doesn't solve the root cause, but actually I can't judge > >> this, because I am missing a description of what is really going > >> wrong. > > > > As I've already said, this isn't about solving the root cause. It's > > about reducing the impact of damage that's already been done until > > the root cause is solved properly. > > My clear vote is No. We shouldn't implement anything which allows bad > coding anywhere, just for the sake of having it "solved" now. The bad coding has already happened. Are you volunteering to revert the Ruby virtuals? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 23.06.2012 18:53, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 18:47:26 +0200 > Justin wrote: >> On 23.06.2012 18:17, Ciaran McCreesh wrote: >>> On Sat, 23 Jun 2012 18:13:23 +0200 >>> Justin wrote: Did you read what you wrote and thought about what you request from others? Probably you better should. >>> >>> Uh huh, and I think we all know there's a huge difference between >>> knowing what versions and slots are and knowing what "a multilib" >>> is. >>> >> >> Might be right, but that doesn't allow you to break your own rules. >> Plus I still don't get the problem of using SLOTS in the way they are >> used now. > > "My own rules" are that enough material is presented that the relevant > people understand it. If you look at simple proposals like usex, silent > rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for > very little in the way of text in cases where the change is easily > understood. > >> And I can't find this out by simply googling. In contrast, an >> explanation of multilib in context of linux distribution and more >> specific gentoo can be found easily. > > Oh really? I was under the impression that there wasn't even general > agreement upon whether or not multilib applied to "C" or to "C, and > Python, and things like it". > >> Stop acting in this arrogant way you are doing right now. > > Come on. Submitting a simple proposal with at least as much detail as > was provided for other, equally simple proposals is "arrogant" now? > >>> That's covered in the devmanual and in the user documentation, so >>> there's no need to repeat it here. >> >> Ever heard about references. They are good, if you don't like to >> repeat what is written, but which are necessary context to understand >> what you are writing. You should use them for the sake of >> understanding, if you are to lazy to write it out again. > > Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where > it references what "phase functions" are, or the proposal for usex and > say where it references what "use flags" are, or the proposal for > silent rules where it references what "econf" is. > To me, it doesn't solve the root cause, but actually I can't judge this, because I am missing a description of what is really going wrong. >>> >>> As I've already said, this isn't about solving the root cause. It's >>> about reducing the impact of damage that's already been done until >>> the root cause is solved properly. >> >> My clear vote is No. We shouldn't implement anything which allows bad >> coding anywhere, just for the sake of having it "solved" now. > > The bad coding has already happened. Are you volunteering to revert the > Ruby virtuals? > I give up. And actually I don't care anymore. When I saw the first people leaving this project, because of all this non social bitching, I thought by myself, this will never happen to me. But the amount of fruitful discussion here is so less compared to the shire amount crap coming through, that it is not worth following it. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:17 AM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 18:13:23 +0200 > Justin wrote: >> Did you read what you wrote and thought about what you request from >> others? Probably you better should. > > Uh huh, and I think we all know there's a huge difference between > knowing what versions and slots are and knowing what "a multilib" is. > >> An example: >> >> "...slots and versions to "mean" something other than what they used >> to,..." >> >> is completely useless without a description of what SLOTS are about >> and how the should be used. And what is the wrong usage you can find; >> examples are necessary here for understanding. > > That's covered in the devmanual and in the user documentation, so > there's no need to repeat it here. http://devmanual.gentoo.org/general-concepts/slotting/index.html http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies I don't think the documentation forbids what these developers are doing. I think you implemented a nice heuristic for your users in your resolver that used to work because slots had a typical set of users cases and the heuristic performed well in those cases. Now people are occasionally using slots in a different way and your heuristic penalizes those cases. That sucks, but you might have to actually change your resolver because I don't think 'funky-slots' properties is going to garner much adoption. It just appears that the heuristic you used to use isn't helpful anymore (or has too any false positives, or whatever.) -A > >> To me, it doesn't solve the root cause, but actually I can't judge >> this, because I am missing a description of what is really going >> wrong. > > As I've already said, this isn't about solving the root cause. It's > about reducing the impact of damage that's already been done until the > root cause is solved properly. > > -- > Ciaran McCreesh
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
El sáb, 23-06-2012 a las 17:53 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 18:47:26 +0200 > Justin wrote: > > On 23.06.2012 18:17, Ciaran McCreesh wrote: > > > On Sat, 23 Jun 2012 18:13:23 +0200 > > > Justin wrote: > > >> Did you read what you wrote and thought about what you request from > > >> others? Probably you better should. > > > > > > Uh huh, and I think we all know there's a huge difference between > > > knowing what versions and slots are and knowing what "a multilib" > > > is. > > > > > > > Might be right, but that doesn't allow you to break your own rules. > > Plus I still don't get the problem of using SLOTS in the way they are > > used now. > > "My own rules" are that enough material is presented that the relevant > people understand it. If you look at simple proposals like usex, silent > rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for > very little in the way of text in cases where the change is easily > understood. > > > And I can't find this out by simply googling. In contrast, an > > explanation of multilib in context of linux distribution and more > > specific gentoo can be found easily. > > Oh really? I was under the impression that there wasn't even general > agreement upon whether or not multilib applied to "C" or to "C, and > Python, and things like it". > > > Stop acting in this arrogant way you are doing right now. > > Come on. Submitting a simple proposal with at least as much detail as > was provided for other, equally simple proposals is "arrogant" now? Did you send this proposal seriously or only to troll comparing it with what you think tommy did with multilib thread? If this is seriously, could you explain more how paludis behave in this case? Looks like it treats SLOT with major number as latest version, that is not always true and I don't understand why it should be always true as there are cases where upstream could release newer 3.0.x releases that are really newer than 3.1.x versions. Current -r300/200 stuff shouldn't break as it's only used to slot libraries and that libs will only be installed when some app RDEPENDs on them. > > > > That's covered in the devmanual and in the user documentation, so > > > there's no need to repeat it here. > > > > Ever heard about references. They are good, if you don't like to > > repeat what is written, but which are necessary context to understand > > what you are writing. You should use them for the sake of > > understanding, if you are to lazy to write it out again. > > Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where > it references what "phase functions" are, or the proposal for usex and > say where it references what "use flags" are, or the proposal for > silent rules where it references what "econf" is. > > > >> To me, it doesn't solve the root cause, but actually I can't judge > > >> this, because I am missing a description of what is really going > > >> wrong. > > > > > > As I've already said, this isn't about solving the root cause. It's > > > about reducing the impact of damage that's already been done until > > > the root cause is solved properly. > > > > My clear vote is No. We shouldn't implement anything which allows bad > > coding anywhere, just for the sake of having it "solved" now. > > The bad coding has already happened. Are you volunteering to revert the > Ruby virtuals? > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 10:16:42 -0700 Alec Warner wrote: > I don't think the documentation forbids what these developers are > doing. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 "This means that counting goes as follows: 1.0 (initial version), 1.0-r1, 1.0-r2, etc." It's not illegal, but it's also not in line with how versions and slots have interacted up until now. > I think you implemented a nice heuristic for your users in your > resolver that used to work because slots had a typical set of users > cases and the heuristic performed well in those cases. > > Now people are occasionally using slots in a different way and your > heuristic penalizes those cases. That sucks, but you might have to > actually change your resolver because I don't think 'funky-slots' > properties is going to garner much adoption. You mean, instead of implementing trivial marking, which takes developers a few seconds, you want to screw over users? I think that says a lot about Gentoo's attitude... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On 24 June 2012 05:16, Alec Warner wrote: >> >> That's covered in the devmanual and in the user documentation, so >> there's no need to repeat it here. > > http://devmanual.gentoo.org/general-concepts/slotting/index.html > http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies > > I don't think the documentation forbids what these developers are > doing. I think you implemented a nice heuristic for your users in your > resolver that used to work because slots had a typical set of users > cases and the heuristic performed well in those cases. > > Now people are occasionally using slots in a different way and your > heuristic penalizes those cases. That sucks, but you might have to > actually change your resolver because I don't think 'funky-slots' > properties is going to garner much adoption. It just appears that the > heuristic you used to use isn't helpful anymore (or has too any false > positives, or whatever.) > It seems to me that the defacto understanding of slots is that given 2 slots for one package, one slot will be a natural upgrade from another competing slot, assuming a slot that is a version progression. This makes sense for most packages. However, it seems slots are in some cases being used for purposes other than natural version progressions, and representing siblings instead of child/parent , and in such case, its not logical to want to install a different sibling simply for having a different sibling installed. So the request is to have some sort of metadata to optionally convey the intent of what the slot "means", where the defacto method would be "They're versions, if X > Y then X is a natural upgrade from Y, and is slotted for transition and similar reasons" , which would indicate to UA's that if they have Y, and X becomes available, that they will want to install X. And there would be the alternative(s), "Funky slots" , where slots DONT indicate version progression, and so should *not* be 'upgraded' to from alternative slots. Logical place to store such information to me seems -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 19:23:57 +0200 Pacho Ramos wrote: > Did you send this proposal seriously or only to troll comparing it > with what you think tommy did with multilib thread? Uhm, this proposal is exactly in line with dozens of others that have been made for EAPI 5. It's simple, low impact and easy to understand. Please explain for everyone's benefit how you think this proposal is in any way different to the EBUILD_PHASE_FUNC proposal, or the usex proposal, or the silent rules proposal. > If this is seriously, could you explain more how paludis behave in > this case? Looks like it treats SLOT with major number as latest > version, that is not always true and I don't understand why it should > be always true as there are cases where upstream could release newer > 3.0.x releases that are really newer than 3.1.x versions. It treats -r300 as being newer than -r200, and so will treat "the gtk3 version" or "the jruby version" as being newer versions of "the gtk2 version" or "the ruby 1.8 version", just as it tries to bring in a newer GCC and so on. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 10:24 AM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 10:16:42 -0700 > Alec Warner wrote: >> I don't think the documentation forbids what these developers are >> doing. > > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 > > "This means that counting goes as follows: 1.0 (initial version), > 1.0-r1, 1.0-r2, etc." > > It's not illegal, but it's also not in line with how versions and slots > have interacted up until now. I agree and I sympathize with your position. > >> I think you implemented a nice heuristic for your users in your >> resolver that used to work because slots had a typical set of users >> cases and the heuristic performed well in those cases. >> >> Now people are occasionally using slots in a different way and your >> heuristic penalizes those cases. That sucks, but you might have to >> actually change your resolver because I don't think 'funky-slots' >> properties is going to garner much adoption. > > You mean, instead of implementing trivial marking, which takes > developers a few seconds, you want to screw over users? I think that > says a lot about Gentoo's attitude... I don't think portage has the behavior that paludis does, so most users are not likely to experience this particular problem. You know as well as I that the marking isn't necessarily trivial. Its another thing we have to document and train people to use. I don't think users get 'screwed over' either. It could be that instead of Gentoo tagging a bunch of ebuilds, you just change your resolver heuristic a bit. -A > > -- > Ciaran McCreesh
[gentoo-dev] Patch: Linguas USE support for cmake-utils.eclass
Hi,
A number of package using cmake and qmake currently do something like this:
LANGS="en de fr"
for x in ${LANGS}; do
IUSE="${IUSE} linguas_${x}"
done
This is ugly, so for some time the loop has been included in qt4-r2, and
I'd also like to add it to cmake-utils.
As far as I can see, this change will have no visible effect on ebuilds
that already manually include the loop, and will cause only one package
to get linguas_* flags that it doesn't already have (which I'll fix).
Thoughts?
--- cmake-utils.eclass
+++ cmake-utils.eclass
@@ -20,0 +21,29 @@
+# @ECLASS-VARIABLE: LANGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# In case your application provides various translations, use this
variable to specify
+# them in order to populate "linguas_*" IUSE automatically. Make sure
that you set this
+# variable before inheriting cmake-utils eclass.
+# Example:
+# @CODE
+# LANGS="en el de"
+# @CODE
+for x in ${LANGS}; do
+ IUSE+=" linguas_${x}"
+done
+
+# @ECLASS-VARIABLE: LANGSLONG
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Same as above, but this variable is for LINGUAS that must be in long
format.
+# Remember to set this variable before inheriting cmake-utils eclass.
+# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
+# Example:
+# @CODE
+# LANGS="de_DE hu_HU"
+# @CODE
+for x in ${LANGSLONG}; do
+ IUSE+=" linguas_${x%_*}"
+done
+unset x
+
Best regards,
Michael
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 10:35:36 -0700 Alec Warner wrote: > I don't think portage has the behavior that paludis does, so most > users are not likely to experience this particular problem. You know > as well as I that the marking isn't necessarily trivial. But this time it is trivial. That's the point. > It could be that instead of Gentoo tagging a bunch of ebuilds, you > just change your resolver heuristic a bit. The resolver heuristic is correct, except in the cases where people are doing utterly weird things with revisions and slots. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
El sáb, 23-06-2012 a las 18:30 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 19:23:57 +0200 > Pacho Ramos wrote: > > Did you send this proposal seriously or only to troll comparing it > > with what you think tommy did with multilib thread? > > Uhm, this proposal is exactly in line with dozens of others that have > been made for EAPI 5. It's simple, low impact and easy to understand. > Please explain for everyone's benefit how you think this proposal is in > any way different to the EBUILD_PHASE_FUNC proposal, or the usex > proposal, or the silent rules proposal. > > > If this is seriously, could you explain more how paludis behave in > > this case? Looks like it treats SLOT with major number as latest > > version, that is not always true and I don't understand why it should > > be always true as there are cases where upstream could release newer > > 3.0.x releases that are really newer than 3.1.x versions. > > It treats -r300 as being newer than -r200, and so will treat "the gtk3 > version" or "the jruby version" as being newer versions of "the gtk2 > version" or "the ruby 1.8 version", just as it tries to bring in a > newer GCC and so on. > And what problems is that causing for you? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 19:43:10 +0200 Pacho Ramos wrote: > > It treats -r300 as being newer than -r200, and so will treat "the > > gtk3 version" or "the jruby version" as being newer versions of > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to > > bring in a newer GCC and so on. > > And what problems is that causing for you? The problem is that there's no way of knowing that -r300 is not "a newer version" than -r200, and that the jruby implementation is not "a newer version" than the ruby 1.8 implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 18:45:46 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 19:43:10 +0200 > Pacho Ramos wrote: > > > It treats -r300 as being newer than -r200, and so will treat "the > > > gtk3 version" or "the jruby version" as being newer versions of > > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to > > > bring in a newer GCC and so on. > > > > And what problems is that causing for you? > > The problem is that there's no way of knowing that -r300 is not "a > newer version" than -r200 It is a newer version. That's why it has a newer revision. > and that the jruby implementation is not "a > newer version" than the ruby 1.8 implementation. And that's another thing which is ugly and should be replaced by something sane rather than worked around. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Patch: Linguas USE support for cmake-utils.eclass
On Sun, 24 Jun 2012 03:37:59 +1000
Michael Palimaka wrote:
> --- cmake-utils.eclass
> +++ cmake-utils.eclass
> @@ -20,0 +21,29 @@
> +# @ECLASS-VARIABLE: LANGS
Please prefix.
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# In case your application provides various translations, use this
> variable to specify
> +# them in order to populate "linguas_*" IUSE automatically. Make
> sure that you set this
> +# variable before inheriting cmake-utils eclass.
> +# Example:
> +# @CODE
> +# LANGS="en el de"
> +# @CODE
> +for x in ${LANGS}; do
> + IUSE+=" linguas_${x}"
> +done
> +
> +# @ECLASS-VARIABLE: LANGSLONG
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Same as above, but this variable is for LINGUAS that must be in
> long format.
> +# Remember to set this variable before inheriting cmake-utils eclass.
> +# Look at ${PORTDIR}/profiles/desc/linguas.desc for details.
> +# Example:
> +# @CODE
> +# LANGS="de_DE hu_HU"
> +# @CODE
Shouldn't this be LANGSLONG?
> +for x in ${LANGSLONG}; do
> + IUSE+=" linguas_${x%_*}"
> +done
> +unset x
> +
And how does it exactly differ from LANGS above? Is there a reason
those two can't be coerced into a single variable?
Shouldn't those do something more than setting IUSE? For example,
actually ensuring those LINGUAS will be installed?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
El sáb, 23-06-2012 a las 18:45 +0100, Ciaran McCreesh escribió: > On Sat, 23 Jun 2012 19:43:10 +0200 > Pacho Ramos wrote: > > > It treats -r300 as being newer than -r200, and so will treat "the > > > gtk3 version" or "the jruby version" as being newer versions of > > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to > > > bring in a newer GCC and so on. > > > > And what problems is that causing for you? > > The problem is that there's no way of knowing that -r300 is not "a > newer version" than -r200, and that the jruby implementation is not "a > newer version" than the ruby 1.8 implementation. > Regarding -r300 issue (I don't know much about ruby), I guess paludis wants to install net-libs/webkit-gtk-1.8.1-r301 for example when nothing is requiring any specific SLOT? What problems does it cause apart of what would cause if ebuilds using gtk2 are RDEPENDing on plain x11-libs/gtk+ without specifying any SLOT? In both cases gtk2 apps should RDEPEND specifically in SLOTs for gtk2 support and gtk3 apps on gtk3 slots. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 19:54:13 +0200 Michał Górny wrote: > On Sat, 23 Jun 2012 18:45:46 +0100 > Ciaran McCreesh wrote: > > On Sat, 23 Jun 2012 19:43:10 +0200 > > Pacho Ramos wrote: > > > > It treats -r300 as being newer than -r200, and so will treat > > > > "the gtk3 version" or "the jruby version" as being newer > > > > versions of "the gtk2 version" or "the ruby 1.8 version", just > > > > as it tries to bring in a newer GCC and so on. > > > > > > And what problems is that causing for you? > > > > The problem is that there's no way of knowing that -r300 is not "a > > newer version" than -r200 > > It is a newer version. That's why it has a newer revision. That's just it, though -- this no longer holds. -r300 is now being used for something that is exactly the same version as -r200. > > and that the jruby implementation is not "a > > newer version" than the ruby 1.8 implementation. > > And that's another thing which is ugly and should be replaced by > something sane rather than worked around. I agree. But until that happens, which probably isn't going to be anytime soon, we need to know where something weird is happening, and that's what this proposal provides. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 18:56:42 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 19:54:13 +0200 > Michał Górny wrote: > > On Sat, 23 Jun 2012 18:45:46 +0100 > > Ciaran McCreesh wrote: > > > On Sat, 23 Jun 2012 19:43:10 +0200 > > > Pacho Ramos wrote: > > > > > It treats -r300 as being newer than -r200, and so will treat > > > > > "the gtk3 version" or "the jruby version" as being newer > > > > > versions of "the gtk2 version" or "the ruby 1.8 version", just > > > > > as it tries to bring in a newer GCC and so on. > > > > > > > > And what problems is that causing for you? > > > > > > The problem is that there's no way of knowing that -r300 is not "a > > > newer version" than -r200 > > > > It is a newer version. That's why it has a newer revision. > > That's just it, though -- this no longer holds. -r300 is now being > used for something that is exactly the same version as -r200. Did you look at SONAME? > > > and that the jruby implementation is not "a > > > newer version" than the ruby 1.8 implementation. > > > > And that's another thing which is ugly and should be replaced by > > something sane rather than worked around. > > I agree. But until that happens, which probably isn't going to be > anytime soon, we need to know where something weird is happening, and > that's what this proposal provides. Yes, let's introduce some random 'funky' word for a single ebuild. Or.. since it's just a single package, maybe you would just add an ignore list to paludis. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 20:09:03 +0200 Michał Górny wrote: > > That's just it, though -- this no longer holds. -r300 is now being > > used for something that is exactly the same version as -r200. > > Did you look at SONAME? Look at SONAME before deciding what package to install? Kindly explain how that works. > > > > and that the jruby implementation is not "a > > > > newer version" than the ruby 1.8 implementation. > > > > > > And that's another thing which is ugly and should be replaced by > > > something sane rather than worked around. > > > > I agree. But until that happens, which probably isn't going to be > > anytime soon, we need to know where something weird is happening, > > and that's what this proposal provides. > > Yes, let's introduce some random 'funky' word for a single ebuild. > Or.. since it's just a single package, maybe you would just add an > ignore list to paludis. a) it's not a single package, and b) ignore lists in a package manager is a terrible idea. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 19:06:38 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 20:09:03 +0200 > Michał Górny wrote: > > > That's just it, though -- this no longer holds. -r300 is now being > > > used for something that is exactly the same version as -r200. > > > > Did you look at SONAME? > > Look at SONAME before deciding what package to install? Kindly explain > how that works. I'm just saying that these are two different versions of the package. If you want GTK+3, you take the newer one. If you want GTK+2 compat, you take the older slot. What's wrong with that? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 14:40:50 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 15:33:47 +0200 > Gilles Dartiguelongue wrote: > > Well the problem is simple, we need to ship webkit with gtk2 and > > gtk3 support. This is needed because gentoo has gtk2 based > > desktop/apps and because we want to ship gnome3 for example. > > > > Cool thing is that webkit supports being built with each toolkit > > without conflicting with the build from the other toolkit hence we > > ended up using SLOTS. > > You could just have gtk2 and gtk3 use flags in the ebuild, use > REQUIRED_USE to ensure that at least one is enabled, and build things > twice in the ebuild if necessary. Ah, so because a few paludis users may be building an additional variant of webkit-gtk unnecessarily, we should force all Gentoo users to randomly rebuild 1-2 variants depending on how soon they're going to get the USE correctly. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 20:23:13 +0200 Michał Górny wrote: > On Sat, 23 Jun 2012 19:06:38 +0100 > Ciaran McCreesh wrote: > > On Sat, 23 Jun 2012 20:09:03 +0200 > > Michał Górny wrote: > > > > That's just it, though -- this no longer holds. -r300 is now > > > > being used for something that is exactly the same version as > > > > -r200. > > > > > > Did you look at SONAME? > > > > Look at SONAME before deciding what package to install? Kindly > > explain how that works. > > I'm just saying that these are two different versions of the package. > If you want GTK+3, you take the newer one. If you want GTK+2 compat, > you take the older slot. What's wrong with that? The package mangler does not know that 1.1-r300 is not a "better" version than 1.1-r200, or that 1.2-r200 is not a "better" version than 1.1-r300. Indicating packages where this kind of strangeness happens allows manglers to know that things that are usually true about the relationship between slots and versions no longer hold, and that in these specific cases it should consider slots to be heavily independent. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Patch: Linguas USE support for cmake-utils.eclass
On Saturday 23 June 2012 13:37:59 Michael Palimaka wrote:
> +for x in ${LANGS}; do
> + IUSE+=" linguas_${x}"
> +done
if you don't want to make it into an array:
IUSE+=" $(printf 'linguas_%s ' ${LANGS})"
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, 23 Jun 2012 20:26:01 +0200 Michał Górny wrote: > > You could just have gtk2 and gtk3 use flags in the ebuild, use > > REQUIRED_USE to ensure that at least one is enabled, and build > > things twice in the ebuild if necessary. > > Ah, so because a few paludis users may be building an additional > variant of webkit-gtk unnecessarily, we should force all Gentoo users > to randomly rebuild 1-2 variants depending on how soon they're going > to get the USE correctly. No. Because the ebuilds would be abusing functionality in a fairly horrible way, we should avoid doing that until we have a good solution in place. Or, looking at it another way, Portage's upgrade rules shouldn't be locked in place because of weird behaviour from a few packages. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2012 07:08 PM, Ciaran McCreesh wrote: > No, your goal is to provide a distribution. Gentoo has repeatedly > shot itself in the foot, leg, groin etc by favouring short-term > hacks over a well thought out, validated, self-enforcing design. > Right now nearly all of the package manager work is on paying off > previously incurred technical debt, and in the mean time you're > busy adding to it. > Please take your exherbo trolling somewhere else. Our goal is not to provide a distribution, because gentoo sees itself as a metadistribution. Please familiarize yourself with: http://www.gentoo.org/main/en/about.xml -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP5guCAAoJEFpvPKfnPDWz6sMH+wVghjCDgYUv6sQzuFCm/xyO gi5fUBRQR7OcpG2KmWsZE6WHLFd1StsoVYwkJB3phwwLeP3P6oEuGvyfjOjY3iIb m8jqbVWbFm9YDS58koGktU7zhOWXbsj/hi3XrbCz2qYlKF23rJfubGehlaNZHIQf OpkBoO1kuPC6AJtJdcY8iXEbneZ7NY/OMOHGasZB/B6O51anbBZ3nuSu1GDbQJ47 NbnJIG/Iuf2FiLgCOCNicRjnnd0AEoQMIhXkrhLcixYNJJ3BMWxPLUA/uJshXUtg HiJqVGEv0ljGgo45rQIDZo5w44tgdOQ7nH6C6criBFKU6/wlbbnbH6ZFpW1Dg9o= =iWGS -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 19:22:37 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 20:23:13 +0200 > Michał Górny wrote: > > On Sat, 23 Jun 2012 19:06:38 +0100 > > Ciaran McCreesh wrote: > > > On Sat, 23 Jun 2012 20:09:03 +0200 > > > Michał Górny wrote: > > > > > That's just it, though -- this no longer holds. -r300 is now > > > > > being used for something that is exactly the same version as > > > > > -r200. > > > > > > > > Did you look at SONAME? > > > > > > Look at SONAME before deciding what package to install? Kindly > > > explain how that works. > > > > I'm just saying that these are two different versions of the > > package. If you want GTK+3, you take the newer one. If you want > > GTK+2 compat, you take the older slot. What's wrong with that? > > The package mangler does not know that 1.1-r300 is not a "better" > version than 1.1-r200, or that 1.2-r200 is not a "better" version than > 1.1-r300. Indicating packages where this kind of strangeness happens > allows manglers to know that things that are usually true about the > relationship between slots and versions no longer hold, and that in > these specific cases it should consider slots to be heavily > independent. It *is* a 'better' version, much like gtk+-3.* is 'better' than gtk+-2.*. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:22 PM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 20:23:13 +0200 > Michał Górny wrote: >> On Sat, 23 Jun 2012 19:06:38 +0100 >> Ciaran McCreesh wrote: >> > On Sat, 23 Jun 2012 20:09:03 +0200 >> > Michał Górny wrote: >> > > > That's just it, though -- this no longer holds. -r300 is now >> > > > being used for something that is exactly the same version as >> > > > -r200. >> > > >> > > Did you look at SONAME? >> > >> > Look at SONAME before deciding what package to install? Kindly >> > explain how that works. >> >> I'm just saying that these are two different versions of the package. >> If you want GTK+3, you take the newer one. If you want GTK+2 compat, >> you take the older slot. What's wrong with that? > > The package mangler does not know that 1.1-r300 is not a "better" > version than 1.1-r200, or that 1.2-r200 is not a "better" version than > 1.1-r300. Indicating packages where this kind of strangeness happens > allows manglers to know that things that are usually true about the > relationship between slots and versions no longer hold, and that in > these specific cases it should consider slots to be heavily independent. You already have this info, it's called a "slot dependency". -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 21:35:47 +0300 Alex Alexander wrote: > > The package mangler does not know that 1.1-r300 is not a "better" > > version than 1.1-r200, or that 1.2-r200 is not a "better" version > > than 1.1-r300. Indicating packages where this kind of strangeness > > happens allows manglers to know that things that are usually true > > about the relationship between slots and versions no longer hold, > > and that in these specific cases it should consider slots to be > > heavily independent. > > You already have this info, it's called a "slot dependency". It's not a property of individual packages that happen to depend upon the problematic package. The property holds or not for a package regardless of whether anything depends upon it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 9:37 PM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 21:35:47 +0300 > Alex Alexander wrote: >> > The package mangler does not know that 1.1-r300 is not a "better" >> > version than 1.1-r200, or that 1.2-r200 is not a "better" version >> > than 1.1-r300. Indicating packages where this kind of strangeness >> > happens allows manglers to know that things that are usually true >> > about the relationship between slots and versions no longer hold, >> > and that in these specific cases it should consider slots to be >> > heavily independent. >> >> You already have this info, it's called a "slot dependency". > > It's not a property of individual packages that happen to depend upon > the problematic package. The property holds or not for a package > regardless of whether anything depends upon it. They are part of the deal. If your package has reverse deps, you don't want to update it before figuring out it's reverse dependencies anyway, you never know what slot/version restrictions you're going to get. If it is a package without reverse dependencies, updating to the most recent slot and/or version should be expected unless the user has the slot defined in the world file. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 22:14:32 +0300 Alex Alexander wrote: > If it is a package without reverse dependencies, updating to the most > recent slot and/or version should be expected unless the user has the > slot defined in the world file. That's the part that no longer holds. The package mangler now needs a way of knowing that for a certain few packages, bringing in new slots when not explicitly required is undesirable. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 22:14:32 +0300 > Alex Alexander wrote: >> If it is a package without reverse dependencies, updating to the most >> recent slot and/or version should be expected unless the user has the >> slot defined in the world file. > > That's the part that no longer holds. The package mangler now needs a > way of knowing that for a certain few packages, bringing in new slots > when not explicitly required is undesirable. Or the PM can notify the user that a new slot has come up and instruct them to specify their desired slot in their world file. -- Alex
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 22:27:03 +0300 Alex Alexander wrote: > On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh > wrote: > > On Sat, 23 Jun 2012 22:14:32 +0300 > > Alex Alexander wrote: > >> If it is a package without reverse dependencies, updating to the > >> most recent slot and/or version should be expected unless the user > >> has the slot defined in the world file. > > > > That's the part that no longer holds. The package mangler now needs > > a way of knowing that for a certain few packages, bringing in new > > slots when not explicitly required is undesirable. > > Or the PM can notify the user that a new slot has come up and instruct > them to specify their desired slot in their world file. But why? The package mangler could automatically do the right thing, without requiring help from a user who probably doesn't know about all of this, if only the small number of packages that did funky things with revisions and slots said so. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Bugzilla whine mail "spam"
Guys, that was a test. I didn't expect it to write "You will get this message once a day until you've dealt with these" so don't take it too serious. I'm sorry about that but i just saw that *a lot* of bugs have been changed from CONFIRMED to IN_PROGRESS.. sorry.. but *that* is more than just wrong.. that is ... If you're scared or annoyed than you should at least complain first. You should rather try to fix bugs instead of confusing the *users* by marking bugs as IN_PROGRESS when nobody actually works on it at all. So again: There will be no daily Bugzilla whines and esp. no global whines! We *may* enable it as a yearly job or so but there are no serious plans yet! -- Regards, Christian Ruppert Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 pgpYrGqGooCeq.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla whine mail "spam"
On 06/23/12 at 09:37PM +0200, Christian Ruppert wrote:
> Guys,
>
> that was a test. I didn't expect it to write "You will get this message once a
> day until you've dealt with these" so don't take it too serious. I'm sorry
> about
> that but i just saw that *a lot* of bugs have been changed from CONFIRMED to
> IN_PROGRESS..
> sorry.. but *that* is more than just wrong.. that is ...
> If you're scared or annoyed than you should at least complain first.
>
> You should rather try to fix bugs instead of confusing the *users* by marking
> bugs as IN_PROGRESS when nobody actually works on it at all.
>
> So again: There will be no daily Bugzilla whines and esp. no global whines!
> We *may* enable it as a yearly job or so but there are no serious plans yet!
>
> --
> Regards,
> Christian Ruppert
> Gentoo Linux developer, Bugzilla administrator and Infrastructure member
> Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8
It just turned out that at least parts of that template seem to be outdated.
E.g. #3:
(3) You decide the [% terms.bug %] belongs to you, but you can't solve it
this moment. Accept the [% terms.bug %] by setting the status to
[% display_value("bug_status", "IN_PROGRESS") %].
That was actually meant for when we had the ASSIGNED status for which it would
make more sense.
Again: Don't take it too serious, if it helps to remind you that's fine but
ignore anything else.
--
Regards,
Christian Ruppert
Gentoo Linux developer, Bugzilla administrator and Infrastructure member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8
pgpdY9CMRHBWY.pgp
Description: PGP signature
Re: [gentoo-dev] Bugzilla whine mail "spam"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/23/2012 09:59 PM, Christian Ruppert wrote: > Again: Don't take it too serious, if it helps to remind you that's > fine but ignore anything else. It'd be cool to exclude STABLEREQs, but I support the reminder characteristic. - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/mKAIACgkQknrdDGLu8JCfLAD+PwgOeBcsslpq/xNB4nBy6VvK 9AaFw3pCU3xVT6K7818A/0F0NqL0sF0iBlO1ic9zsGySFCv8xtQdNeMOA3YABE2j =NOoJ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote: > > > Is it that Paludis installs a newer SLOT even if a reverse > dependency > > explicitly requests another SLOT? Sounds like a bug to me. > > No, it's that if a user requests a "complete" resolution, Paludis > installs the newest version of things that it can. Extensive > consultation with users has shown that this is a good behaviour, > except > in the small number of situations that have recently arisen where > people are doing weird things with versions and slots. It surprises me that this behavior is normally desirable for packages where all dependencies (including any in the world set or the like) are slotted. The first example that comes to mind here is gtk+: if all packages a user has installed that depend on gtk+ explicitly depend on slot 2 (which is probably uncommon now but reasonable back when gtk 3 was introduced), and they do not have gtk+ in their world file (which is reasonable), do your users really expect the package manager to install gtk 3? If your package manager has a feature similar to emerge --depclean, shouldn't this then suggest immediately removing it again, as nothing depends on it? I would argue that library versions that can be installed side-by-side, like gtk+ 2 and 3, "fit the traditional way of how slots worked". But I think automatically pulling in the latest and greatest version of such a library only makes sense if code written against the old library stands a chance of making use of the new library. It might make sense to add a way to inform your package manager if pulling in new slots by default is useful, but I would prefer to give this a more obvious name than "funky-slots", and to come up with a better approach for deciding whether or not the property should be set than "is SLOTS being used for something "clever" or not". I would also suggest that the default should be to *not* pull in new slots by default, but perhaps some review of how slotting is most commonly used would help decide on that. -- Marien Zwart
Re: [gentoo-dev] Bugzilla whine mail "spam"
Michael Weber schrieb: > On 06/23/2012 09:59 PM, Christian Ruppert wrote: >> Again: Don't take it too serious, if it helps to remind you that's >> fine but ignore anything else. > > It'd be cool to exclude STABLEREQs, but I support the reminder > characteristic. I think STABLEREQs should not be treated differently from other bugs, as they require attention too. After you CC: arches, you could change the status to IN_PROGRESS in order to not receive future reminders. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, 23 Jun 2012 22:36:14 +0200 Marien Zwart wrote: > On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote: > > > Is it that Paludis installs a newer SLOT even if a reverse > > dependency > > > explicitly requests another SLOT? Sounds like a bug to me. > > > > No, it's that if a user requests a "complete" resolution, Paludis > > installs the newest version of things that it can. Extensive > > consultation with users has shown that this is a good behaviour, > > except > > in the small number of situations that have recently arisen where > > people are doing weird things with versions and slots. > > It surprises me that this behavior is normally desirable for packages > where all dependencies (including any in the world set or the like) > are slotted. Think || ( a:3 a:2 ). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
Le samedi 23 juin 2012 à 18:30 +0100, Ciaran McCreesh a écrit : > > It treats -r300 as being newer than -r200, and so will treat "the gtk3 > version" or "the jruby version" as being newer versions of "the gtk2 > version" or "the ruby 1.8 version", just as it tries to bring in a > newer GCC and so on. I'm stopping my reading of this thread a minute to answer here. This is actually true when you think of it, gtk3 bindings are newer than gtk2. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: My wishlist for EAPI 5
Rich Freeman posted on Sat, 23 Jun 2012 07:12:29 -0400 as excerpted: > You can't fix it by beating people up. Volunteers do it on their own terms... or don't do it. The outliers can be moderated to some degree and thankfully the list isn't what it once was, but get too strict and people simply find other things to do. Of course there's a line where letting them find something else to do is best, and some have crossed it, but... > 1. While perhaps a different leader might give people a warmer feeling > about it, I think many of these issues are just inherent to the nature > of the problem - PM features don't write themselves. Others might > disagree, and that is fine. > > 2. I don't see anybody else stepping up. Good points. (Whole post actually, but snipped for brevity.) To some extent, the job of coordinating PMS is going to be a (nearly) thankless task, and it does take a specific kind of person to keep at it. Not everybody's cut out for it. You're right, others /aren't/ stepping up for it and I can't blame them. Thanks for pointing out what we likely all knew if we thought about it, but many (me included) sometimes forget. Back to my original point, tho. Seeing people working on other PMs make the point as well, helps, and I hope to see both a bit more of that and more reminders of it in other subthreads/replies, where appropriate. I know that helps me keep a bit better perspective. =:^) -- 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: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual
On 06/16/2012 02:56 PM, Duncan wrote: > Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets. > Since I've been working with kde4 since it was overlay-only and sets- > only, no meta-packages, I've been using sets for quite awhile and it's > now entirely integrated into how I work with portage. > > When I setup my netbook on gentoo, I wanted most of the same setup as on > my main machine, but with some differences, so I had to go thru the main > machine's world file and pick and choose what I needed. > > What I quickly realized is that my kde packages were already nicely > categorized into sets, so all I really needed to do was split up the rest > of the world file into a bunch of other sets, by category. So for > instance: > > $>>cat /etc/portage/sets/jed.dev > dev-util/ccache > dev-util/desktop-file-utils > dev-vcs/git > sys-devel/bin86 > sys-devel/gcc > sys-devel/gdb > > > I have 24 such sets including my (customized) kde sets. All packages > formerly listed in the world file are found in these sets, instead, and > of course the sets are in turn listed in /var/lib/portage/world_sets. > > My world file is normally entirely empty, tho I do use it occasionally > for packages I haven't decided whether I want to keep or not, but want to > protect from --depclean, which I run after each update. So my world file > serves as a kind of package purgatory, until I decide whether it's going > to be a part of my normal system, or removed. > > The sets, meanwhile, break the former world file down into much more > manageable categorized chunks, each of which is short enough and > categorized specifically enough that if a package is no longer needed, it > immediately sticks out like a sore thumb, as it's not lost among the > noise of hundreds of "twisty packages, all different". =:^) > > > While not a direct solution to the problem at hand, proper use of sets > WILL and DOES dramatically ease gentoo world-package administration, > going a long way toward eliminating crufty world lists simply by allowing > them to be cut into nice little chunks that can be categorized in ways > that make sense for an individual site, so the cruft sticks out like the > sore thumb it can really be, and is thus easily found and removed. > > > Meanwhile, another bonus of sets is the extra protection it gives you if > you try to emerge -C something in a sets file (as opposed to the world > file itself). =:^) Seeing that warning that the package is in a set and > can't be directly unmerged is rather like seeing the warning that it's in > @system, except that user sets are easier to directly manage, and it has > saved my butt a couple times when I was really too sleepy to be adminning > the system in the first place. But it's easy enough to remove (or > comment) that line from the set, if removal is really intended, and > that's what would ultimately need to be done anyway, to prevent it > getting remerged. > > > Unfortunately, it has begun to look like sets are where baselayout2 and > openrc were for many years, "forever coming, never getting here", at > least for stable or even unmasked into ~arch. =:^( Support for /etc/portage/sets is included in portage-2.1.11: https://bugs.gentoo.org/show_bug.cgi?id=384061 -- Thanks, Zac
Re: [gentoo-dev] About forcing rebuilds of other packages issue
On 06/10/2012 11:18 AM, Zac Medico wrote: > On 06/10/2012 05:25 AM, Ciaran McCreesh wrote: >> On Sat, 09 Jun 2012 13:55:53 -0700 >> Zac Medico wrote: >>> A dependency atom will have optional SLOT and ABI_SLOT parts. Using >>> the dbus-glib depedency on glib:2 as an example [1], the dbus-glib >>> dependency will be expressed with an atom such as dev-libs/glib:2:= >>> and the package manager will translate that atom to >>> dev-libs/glib:2:=2.32 at build time. So, ':' is always used to >>> distinguish SLOT deps, and ':=' is always used to distinguish >>> ABI_SLOT deps. Is that syntax good? >> >> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32". Then you >> can do explicit :2/2.32 dependencies if you like, or :2 (which would >> match SLOT="2" or SLOT="2/anything"), or :2= (which gets rewritten >> to :2/2.32=) or :2*. If an ebuild does SLOT="2", it's treated as 2/2. > > Yes, I prefer your syntax. In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI “4-slot-abi”: http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/ -- Thanks, Zac
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 1:31 PM, hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/11/2012 07:08 PM, Ciaran McCreesh wrote: >> No, your goal is to provide a distribution. Gentoo has repeatedly >> shot itself in the foot, leg, groin etc by favouring short-term >> hacks over a well thought out, validated, self-enforcing design. >> Right now nearly all of the package manager work is on paying off >> previously incurred technical debt, and in the mean time you're >> busy adding to it. >> > > Please take your exherbo trolling somewhere else. > > Our goal is not to provide a distribution, because gentoo sees itself > as a metadistribution. > > Please familiarize yourself with: > http://www.gentoo.org/main/en/about.xml Let's keep the discussions on this mailing list technical and not personal. Thanks. -- Doug Goldstein
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 1:26 PM, Michał Górny wrote: > On Sat, 23 Jun 2012 14:40:50 +0100 > Ciaran McCreesh wrote: > >> On Sat, 23 Jun 2012 15:33:47 +0200 >> Gilles Dartiguelongue wrote: >> > Well the problem is simple, we need to ship webkit with gtk2 and >> > gtk3 support. This is needed because gentoo has gtk2 based >> > desktop/apps and because we want to ship gnome3 for example. >> > >> > Cool thing is that webkit supports being built with each toolkit >> > without conflicting with the build from the other toolkit hence we >> > ended up using SLOTS. >> >> You could just have gtk2 and gtk3 use flags in the ebuild, use >> REQUIRED_USE to ensure that at least one is enabled, and build things >> twice in the ebuild if necessary. > > Ah, so because a few paludis users may be building an additional > variant of webkit-gtk unnecessarily, we should force all Gentoo users > to randomly rebuild 1-2 variants depending on how soon they're going to > get the USE correctly. > Let's all agree that the current solution is less than ideal and could use improvement. I have several Gentoo & Portage only desktops and I find myself annoyed with webkit-gtk and its revisions and rebuilds. -- Doug Goldstein
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sat, Jun 23, 2012 at 9:45 AM, Gilles Dartiguelongue wrote: > Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit : >> >> I'd like to know why using USE flags until a nicer solution is >> available >> is sufficiently terrible that it warrants a hackaround. > > remember qt3/qt4, gtk/gtk2. We want to avoid repeating these "mistakes" > hence the guidelines already exposed back when we introduced gtk3 to the > tree. > > As you may have noticed, this is still the solution applied for things > hard to split or slot like gtk-vnc or avahi but we didn't see the need > to have such USE flags when the library was so easily slottable. > It's funny you bring up qt3/qt4 and gtk/gtk2 since I'm only of the few developers that worked on resolving both of those as they came and went. Right now the resources we've got available to us from a Package Manager stand point. Being a Gentoo dev for so long has allowed me to see how our distro has evolved so let me give you a short walk down memory lane, when gtk/gtk2 & qt3/qt4 occurred we had the following: - Portage 1.x (gtk/gtk2) / Portage 2.0.x (qt3/qt4) - No EAPI - No way to add features quickly to the Package Manager and the spec for it. During gtk/gtk2, the rule was you had to wait until a feature was available in the STABLE version of Portage, 4 releases back before you could use a new feature. For everyone's knowledge, we did 4 releases a year then. We knew our solution to gtk/gtk2 sucked and we hated it but there was absolutely nothing we could do about it. It was a bitter battle of band aids and hacks that we couldn't wait to get rid of. We even attempted to throw gtk1 out of the tree entirely (ah the XMMS flamewar) to get rid of the hacks. You couldn't even modify eclasses since they weren't stored with the install, which lead to the -rX revisioning of eclasses. On top of all this, Portage 1.x SUCKED to modify or hack at. The only solution with that codebase was to nuke it from orbit, which we finally did with Portage 2.0.x. During qt3/qt4, the rule was you had to wait until the feature you were trying to use was in a STABLE Portage for 6 months. We didn't have a lot of options available but we worked with the current Portage maintainer at the time to get some of the resolver improved and fixed and get those updates pushed out to the tree as quickly as possible. Once the updates were available the hacks went away and life was better. Now fast forward to 2011/2012, we were obviously aware that the gtk2/gtk3 change would cause some problems. Heck people encountered it when they tried to add ebuilds to the tree. The right path forward was to speak to Zac, Brian and the rest of the PMS guys and see what the best solution was. If it was implementing some new features then we could have done that and gotten and EAPI approved quickly and had it available before we even saw the first gtk3 ebuild unmasked. But alas, that wasn't the case and here we are today. So here's what I suggest, let's stop bickering and revisit the "hacks" you did to make things work. Speak to Zac, Brian and the rest of the PMS guys and get what you need implemented as a feature and get that feature into the very next EAPI bump. Fix the tree to use that EAPI and get rid of the hacks. You'll thank yourselves in the long run since things will be easier to maintain and you can focus on what you enjoy doing. -- Doug Goldstein
Re: [gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass
On Wednesday 20 June 2012 11:56:58 viv...@gmail.com wrote: > Meeting with bug: #409471 suggested that some ebuilds could benefit from > expanding -march=native to the actual flags the compiler use. i can't really see how. if packages can't handle certain flags, then fix those. so NAK on adding anything like this to a common eclass. -mike signature.asc Description: This is a digitally signed message part.
