Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. wrote: > On 9/14/15 6:35 AM, konsolebox wrote: >> Many times we need to match packages like this: something-1.0.2a.* > > Could you give specific examples, i.e. what packages, what dependencies, > why is that needed? For accuracy and peace of mind regardless of how often conflicts could happen. I want to write rules in /etc/portage/package.* and specify dependencies in ebuilds without minding that one atom expression could unexpectedly match another package version on later time. I can't give any example yet, but we know that if pkg-4.1.2 exists and pkg-4.10.0 exists as well, then we can't use '=pkg-4.1*' to only target pkg-4.1.*. This could also happen more often with packages having 4 version numbers.
[gentoo-dev] Re: Request to add ~> atom prefix operator on Portage.
konsolebox posted on Mon, 14 Sep 2015 14:09:03 +0800 as excerpted: > On Mon, Sep 14, 2015 at 1:51 PM, Ulrich Mueller wrote: >> Sorry, but I don't get it. How would these be different from the >> existing "=pkg-1.0.2a*" and "=pkg-1.0.2*"? > > Because they could also match pkg-1.0.2aa (not sure if it's still valid > atom) and pkg-1.0.20 respectively. What about combining (positive) deps and blockers, deping on =pkg-1.0.2a* and blocking >=pkg-1.0.2b ? Wouldn't that resolve the unintended matches? -- 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] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 18:52, Ulrich Mueller wrote: >> No, there isn't any dot implied. It uses simple prefix comparison, >> as in shell globbing. > Ugh. That's really really nasty. I'm going to have to go reprogram > my brain with bleach. :( > I say this because it doesn't strictly make sense in the knowledge > that 1.3 and 1.30 both match =1.3* We could fix this in a future EAPI such that version components would not be split when matching. So =1.3* would not match 1.30 any more because the 30 could only be matched as a whole. OTOH, I am not aware of any problems caused by the current behaviour. Although I agree that it isn't logical. Another interesting example: Which of the following will match the package "cat/foo-1.02.3", and why: =cat/foo-1.020.3 =cat/foo-1.020.3* =cat/foo-01.02.3* (Hint: PMS and Portage don't necessarily agree.) Ulrich pgpGCOjxBsrMO.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:01, Ulrich Mueller wrote: >=cat/foo-1.020.3 >=cat/foo-1.020.3* >=cat/foo-01.02.3* Of those, I only expect the last to match, because leading 0's are not typically significant. However, that "=dev-lang/perl-05.22*" matches dev-lang/perl-5.22.0 but "=dev-lang/perl-5.022*" does not is a complete mystery to me. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 3:58 PM, Duncan <1i5t5.dun...@cox.net> wrote: > konsolebox posted on Mon, 14 Sep 2015 14:09:03 +0800 as excerpted: > >> On Mon, Sep 14, 2015 at 1:51 PM, Ulrich Mueller wrote: >>> Sorry, but I don't get it. How would these be different from the >>> existing "=pkg-1.0.2a*" and "=pkg-1.0.2*"? >> >> Because they could also match pkg-1.0.2aa (not sure if it's still valid >> atom) and pkg-1.0.20 respectively. > > What about combining (positive) deps and blockers, deping on =pkg-1.0.2a* > and blocking >=pkg-1.0.2b ? Wouldn't that resolve the unintended matches? Possible workaround but all I'd say is that it adds complexity or noise. We also do other things besides blocking. Sometimes we just call dependencies, sometimes we just apply or disable flags - such are the cases where doing the opposite action to excluded versions is not always applicable.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:01, Ulrich Mueller wrote: > We could fix this in a future EAPI such that version components would > not be split when matching. So =1.3* would not match 1.30 any more > because the 30 could only be matched as a whole. > > OTOH, I am not aware of any problems caused by the current behaviour. > Although I agree that it isn't logical There's a fringe use here which becomes more obvious with date-suffixed versions like 5.20150602 =5.2015* would be a legitimate and semi-useful condition for applying a mask for use flags etc. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:01 PM, Ulrich Mueller wrote: >> On Mon, 14 Sep 2015, Kent Fredric wrote: > >> On 14 September 2015 at 18:52, Ulrich Mueller wrote: > Another interesting example: Which of the following will match the > package "cat/foo-1.02.3", and why: > >=cat/foo-1.020.3 >=cat/foo-1.020.3* >=cat/foo-01.02.3* If we use an arithmetic operator like ~> then that could be decided easily. First we use a rule that all version numbers are decimal (oct is unlikely), so we simply remove the leading zeros then apply the rule accordingly, which is >=cat/foo-1.20.3 &&
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:22, konsolebox wrote: > If we use an arithmetic operator like ~> then that could be decided As a counter proposal I'd suggest a different suffix character than "*" instead. It just seems less confusing to have something like =cat/foo-1.30+ Instead of ~>cat/foo-1.30 Because ~> to me conveys some combination of ~ and > effects, when it is neither of those two. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: > On 14 September 2015 at 20:22, konsolebox wrote: >> If we use an arithmetic operator like ~> then that could be decided > > As a counter proposal I'd suggest a different suffix character than > "*" instead. It just seems less confusing to have something like > > =cat/foo-1.30+ > > Instead of > > ~>cat/foo-1.30 > > Because ~> to me conveys some combination of ~ and > effects, when it > is neither of those two. I thought ~> is good as it's already famous to fellow Ruby users but I don't mind. =cat/foo-1.30+ seems good as well.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:32 PM, konsolebox wrote: > On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: >> On 14 September 2015 at 20:22, konsolebox wrote: >>> If we use an arithmetic operator like ~> then that could be decided >> >> As a counter proposal I'd suggest a different suffix character than >> "*" instead. It just seems less confusing to have something like >> >> =cat/foo-1.30+ >> >> Instead of >> >> ~>cat/foo-1.30 >> >> Because ~> to me conveys some combination of ~ and > effects, when it >> is neither of those two. > > I thought ~> is good as it's already famous to fellow Ruby users but I > don't mind. =cat/foo-1.30+ seems good as well. @cat/foo-1.30 is also another. It only uses one symbol doesn't look bad if negated: !@cat/foo-1.30
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 20:01, Ulrich Mueller wrote: >> Which of the following will match the package "cat/foo-1.02.3", >> and why: >> >>=cat/foo-1.020.3 >>=cat/foo-1.020.3* >>=cat/foo-01.02.3* > Of those, I only expect the last to match, because leading 0's are > not typically significant. Well, version comparison is described in [1] and it says that =cat/foo-1.020.3 will match cat/foo-1.02.3. The problem is how to read the sentence "if the version specified has an asterisk immediately following it, a string prefix comparison is used instead" in the specification of the = operator [2]. Does that string prefix comparison apply to the whole version (then neither =cat/foo-1.020.3* nor =cat/foo-01.02.3* would match), or only to its last component (then both would match)? Portage behaviour is that =cat/foo-1.020.3* doesn't match but =cat/foo-01.02.3* does. Which seems to disagree with either reading of the spec. Could someone check what is Paludis's behaviour for the examples above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis? Ulrich [1] https://projects.gentoo.org/pms/5/pms.html#x1-290003.3 [2] https://projects.gentoo.org/pms/5/pms.html#x1-840008.2.6.1 pgpWOUt20Onhi.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Well, version comparison is described in [1] and it says that > =cat/foo-1.020.3 will match cat/foo-1.02.3. Surely, as per Algorithm 2, that is false, because "020" and "02" are both integers, and therefor they'd default to integer comparison, and "020" would be deemed ">" "02" And that is most surely what happens in reality too, otherwise, surely, emerge --ignore-default-opts -vaO =dev-lang/perl-5.220.0 Would resolve to perl-5.22.0 Algorithm 3 should only fall into play if one or both of the compontents are non-numeric. Or is "leading 0" a "Non-numeric" condition? Either way, I'm glad nothing really scary happens when I do: emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Could someone check what is Paludis's behaviour for the examples > above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis? Portage: emerge --ignore-default-opts -vpO =dev-lang/perl-5.2* These are the packages that would be merged, in order: [ebuild R] dev-lang/perl-5.22.0:0/5.22::gentoo USE="berkdb doc gdbm -debug -ithreads" 0 KiB Paludis: cave resolve -1 -0 "*/*" =dev-lang/perl-5.2* Done: 4 steps These are the actions I will take, in order: (nothing to do) I encountered the following errors: ! dev-lang/perl Reasons: target Unsuitable candidates: * dev-lang/perl-5.20.2:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target * dev-lang/perl-5.20.2-r1:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target * dev-lang/perl-5.22.0:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 21:04, Ulrich Mueller wrote: >> Well, version comparison is described in [1] and it says that >> =cat/foo-1.020.3 will match cat/foo-1.02.3. > Surely, as per Algorithm 2, that is false, because "020" and "02" are > both integers, and therefor they'd default to integer comparison, and > "020" would be deemed ">" "02" Comparison in Algorithm 2 only takes place for the zeroth component (i.e., "1", for the example above). For all following numeric components Algorithm 3 is called. For the next component, the condition in line 1 is true, so it will remove trailing zeros (i.e., both "020" and "02" will become "02") and then it will use stringwise comparison. That is, versions 1.020.3 and 1.02.3 will be considered equal. Ulrich pgp64ceWpGSTn.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 23:38, Ulrich Mueller wrote: > Comparison in Algorithm 2 only takes place for the zeroth component > (i.e., "1", for the example above). > > For all following numeric components Algorithm 3 is called. For the > next component, the condition in line 1 is true, so it will remove > trailing zeros (i.e., both "020" and "02" will become "02") and then > it will use stringwise comparison. > > That is, versions 1.020.3 and 1.02.3 will be considered equal. It seems that it may not have been implemented that way . Or am I expecting the wrong things when I read that logic and expect that: emerge --ignore-default-opts -vaO =dev-lang/perl-5.022.0 emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 Should both match dev-lang/perl-5.22.0 ? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > Portage: > emerge --ignore-default-opts -vpO =dev-lang/perl-5.2* > These are the packages that would be merged, in order: > [ebuild R] dev-lang/perl-5.22.0:0/5.22::gentoo USE="berkdb doc > gdbm -debug -ithreads" 0 KiB > Paludis: > cave resolve -1 -0 "*/*" =dev-lang/perl-5.2* > Done: 4 steps > These are the actions I will take, in order: > (nothing to do) > [...] Interesting. So Portage follows the wording of the spec (prefix string matching), whereas Paludis behaves like (IMHO) the spec should have been written. Ulrich pgpdmFPTB8AKm.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 01:46 PM, Ulrich Mueller wrote: > > Interesting. So Portage follows the wording of the spec (prefix string > matching), whereas Paludis behaves like (IMHO) the spec should have > been written. > The question is now... can we fix the spec?
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 23:38, Ulrich Mueller wrote: >> That is, versions 1.020.3 and 1.02.3 will be considered equal. > It seems that it may not have been implemented that way . > Or am I expecting the wrong things when I read that logic and expect that: > emerge --ignore-default-opts -vaO =dev-lang/perl-5.022.0 > emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 > Should both match dev-lang/perl-5.22.0 ? No, 5.022.0 and 5.0220.0 are equal to each other, but they are not equal to 5.22.0. Algorithm 3 will remove any trailing zeros of the component, so you'll end up with "022", "022". and "22", which are compared using stringwise comparison. Ulrich pgp5YJzKOz0J9.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, hasufell wrote: > On 09/14/2015 01:46 PM, Ulrich Mueller wrote: >> Interesting. So Portage follows the wording of the spec (prefix >> string matching), whereas Paludis behaves like (IMHO) the spec >> should have been written. > The question is now... can we fix the spec? I could find only two instances of string prefix matching in the tree: - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with WANT_AUTOCONF=2.1). - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". Both should be are easily fixable, in a way that doesn't break backwards compatibility with current Portage. So I think that fixing the spec would be possible, indeed. Ulrich pgpxjt4dASAsg.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14.09.2015 10:41, konsolebox wrote: > On Mon, Sep 14, 2015 at 4:32 PM, konsolebox wrote: >> On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: >>> On 14 September 2015 at 20:22, konsolebox wrote: If we use an arithmetic operator like ~> then that could be decided >>> >>> As a counter proposal I'd suggest a different suffix character than >>> "*" instead. It just seems less confusing to have something like >>> >>> =cat/foo-1.30+ >>> >>> Instead of >>> >>> ~>cat/foo-1.30 >>> >>> Because ~> to me conveys some combination of ~ and > effects, when it >>> is neither of those two. >> >> I thought ~> is good as it's already famous to fellow Ruby users but I >> don't mind. =cat/foo-1.30+ seems good as well. > > @cat/foo-1.30 is also another. It only uses one symbol doesn't look > bad if negated: !@cat/foo-1.30 > Please don't add any more syntactic sugar to dependency strings. People might become confused about stuff like this: =cat/foo-1.3.1_rc3_p20130829-r42+[!a=,!b?,c(+)]:3= Is there any real need to express this in a single line except for saving a single line? - Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, 14 Sep 2015 13:46:34 +0200 Ulrich Mueller wrote: > Interesting. So Portage follows the wording of the spec (prefix string > matching), whereas Paludis behaves like (IMHO) the spec should have > been written. Not so fast! Paludis has two different behaviours for =*, depending upon the context in which they're used. When parsing a user-supplied dependency specification, it uses the sane behaviour. When parsing something that's got an EAPI context, it uses the weird behaviour. You can't test this from the command line... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFI: A better workflow for github pull requests
El lun, 14-09-2015 a las 00:19 +0300, Andrew Savchenko escribió: [...] > Yes, but as long as choice of core components and infrastructure is > free one. Read Gentoo Social Contract: > > https://www.gentoo.org/get-started/philosophy/social-contract.html > > "However, Gentoo will never depend upon a piece of software or > metadata unless it conforms to the GNU General Public License, the > GNU Lesser General Public License, the Creative Commons - > Attribution/Share Alike or some other license approved by the Open > Source Initiative (OSI)." > > What actually happens now is that several individual are trying to > undermine this concept and to tie Gentoo to the proprietary > metadata. And some point this dependence will become irreversible. > It is a pain for me to see that several developers under disguise of > "community" and "integration" are trying hard to make that happen, > step by step. > > Best regards, > Andrew Savchenko I completely disagree with you pointing to some concrete people and accusing them about they trying to break the social contract. I see no proof at all to support your accusation, and I think you should refrain from doing that kind of accusations without any base. If you have any kind of "proof" supporting that accusations, please explain them briefly, otherwise this looks just like trolling to me :/ The only thing I see here is some people trying to mirror github and bugzilla, and that will likely help a lot of people (like me) that don't use github, letting people that need their features to work with other people that don't need or don't want to use it. What is the problem then? :| Why people tend to think that others have obscure intentions or similar? Isn't much easier to think that all people here are contributing for free for the sake of improving things? Why do we need to be so rude when discussing things on mailing lists or IRC? I am sure that if we could meet in the "real life", face to face, we would see that there are no conspiracies and no obscure intentions and most of the arguments come from misunderstandings, overreactions and similar :|
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 9/14/15 9:13 AM, konsolebox wrote: > On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. > wrote: >> On 9/14/15 6:35 AM, konsolebox wrote: >>> Many times we need to match packages like this: >>> something-1.0.2a.* >> >> Could you give specific examples, i.e. what packages, what >> dependencies, why is that needed? > > For accuracy and peace of mind regardless of how often conflicts > could happen. I agree =pkg-4.1* also matching pkg-4.10 is a concern. In that case though, it would change the focus of the discussion to how * operator should work, not necessarily adding a new ~> operator. I think it'd be okay to e.g. change the meaning and behavior of * in a new EAPI. > I can't give any example yet, but we know that if pkg-4.1.2 exists > and pkg-4.10.0 exists as well, then we can't use '=pkg-4.1*' to only > target pkg-4.1.*. This could also happen more often with packages > having 4 version numbers. It's unfortunate this is rather theoretical now. Consider looking for some real examples, I believe this could really help the discussion. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/14/2015 06:35 AM, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > > But that expression is not allowed with ~ (only targets revisions) > and neither with * (.*) is invalid. > > So my suggestion is to add ~> as another operator. With it we can > have an expression like '~>pkg-1.0.2a' and it would be equivalent > to '>=pkg-1.0.2a' and ' '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and > '
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Paweł Hajdan, wrote: > I agree =pkg-4.1* also matching pkg-4.10 is a concern. > In that case though, it would change the focus of the discussion to > how * operator should work, not necessarily adding a new ~> > operator. > I think it'd be okay to e.g. change the meaning and behavior of * in > a new EAPI. Bug 560466 now. Ulrich pgpuHmuPuih9Q.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Montag, 14. September 2015, 15:11:35 schrieb Ulrich Mueller: > > > The question is now... can we fix the spec? > > I could find only two instances of string prefix matching in the tree: > > - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with > WANT_AUTOCONF=2.1). > - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". How *could* you overlook the Perl virtuals? :) (about 150 instances of =dev-lang/perl-5.22* or similar) However, these are standardized enough that any search/replace should be safe, given something has to be fixed. (I haven't followed the esoteric part of the discussion.) (Unless someone insists on a revision bump for each dependency modification - which is where I'd like to reply with an emphatic "Do it yourself then.") - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJV9yaJAAoJEB9VdM6hupKVQK8P/2IsZKEc+aAg+fkqyj+dikvt M40G6+WATRaQHKt7kXRbLfXXyJnjh3J2PyO2AHd3CKwh4jM52U4gEI5xiJDgNxEg pUdH9iR0tFx8ClC0ReaqfvRztizeQNCHiQgBtWzEMHp5BTB4F1NW/zD8juSAI1K6 kpp+Eei17uJjGM/tVQX1FQnZdhp/l/0Iq1bhDJtxpM2aqEcmmK7fipB8ko43EBF9 i38cfRq6feOYmtK7AE4yC0876uCMfTEIcCbGnwO/QIcOGEhvTAQ3vHINoe2W+3wU jnhxONhRAy4ss5E7XkdWF+xNXD9MFJ4Dbarkyr/miwSJhh+vVHKH6R2fXdc6QDAq xYmbWsMf9MG5zspJTx6whyJBUylcYPFH2FnyUrMPhuBpLv2AWeos1RVFruBZsWhG F3QkmXRUAhgqy34GMxLALjWD7EPrkiVV9GZFBirSF3xC23FrSpKYzduvRVLtv6+J UC+UJN/2dT1Ur+yg/c2ikMdBVviXXGqtDc9d30JVTeUpBDD/2B6cZJVcgUPP4TbP 2zQtMT4RZ3GI2sjCUgvcHPer1lVF8G6WHcnc+9uonawVyD0q8YhmHcjf+Csp4OCt PBNtiHmIqm/0Mzek8dHX9qHc6yl6iUwH11oBTiOdetZbWVdPAgSkewzmd/a552a3 jfHwEMTT/T1jdkI2MGDq =yFzT -END PGP SIGNATURE-
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 09:56 PM, Andreas K. Huettel wrote: > > (Unless someone insists on a revision bump for each dependency modification Yes, because everything else will cause a mess.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Andreas K Huettel wrote: > Am Montag, 14. September 2015, 15:11:35 schrieb Ulrich Mueller: >> I could find only two instances of string prefix matching in the tree: >> >> - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with >> WANT_AUTOCONF=2.1). >> - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". > How *could* you overlook the Perl virtuals? :) > (about 150 instances of =dev-lang/perl-5.22* or similar) Nope, these use the asterisk for matching of a version component range. So there is no string prefix ending in the middle of a component. In other words, =dev-lang/perl-5.22* matches version 5.22.0, so no version component is cut into pieces. Which is different for =sys-devel/autoconf-2.1* matching version 2.13. Ulrich pgpuECM3c8fwq.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 01:19 PM, hasufell wrote: > On 09/14/2015 09:56 PM, Andreas K. Huettel wrote: >> >> (Unless someone insists on a revision bump for each dependency modification > > Yes, because everything else will cause a mess. > Performing updates with a behavior like emerge --changed-deps gives similar results. Perhaps all package managers should enable this sort of behavior by default. -- Thanks, Zac
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, hasufell wrote: >> (Unless someone insists on a revision bump for each dependency >> modification > Yes, because everything else will cause a mess. Fortunately, for autotools.eclass it is a pure build-time dependency whose updating doesn't need any revbump. This leaves us with one single package with runtime dependencies. Ulrich pgpSKZzQPA5oR.pgp Description: PGP signature
[gentoo-dev] www-apps/otrs: needs new maintainer
I contacted Robin today asking for how to proceed here, he told me to post here. tl;dr -> https://bugs.gentoo.org/show_bug.cgi?id=506052 shows that * the former dev has removed himself as maintainer * the package is rather outdated now in portage * there are some ebuilds already which could be considered to be added (at least as unstable, sure) pls advise, thanks, Stefan
