Re: [gentoo-dev] Add Hooks to Eselect

On Tue, Aug 22, 2023, 02:50 Ulrich Mueller, wrote: > >>>>> On Mon, 21 Aug 2023, konsolebox wrote: > > > This actually allows users to virtually extend an eselect module without > > needing to fork it. The things people can do are endless. > > This i

Re: [gentoo-dev] Add Hooks to Eselect

On Mon, Aug 21, 2023, 18:00 Ulrich Mueller, wrote: > Sorry, but I don't see much incentive for adding such a hook mechanism. > This actually allows users to virtually extend an eselect module without needing to fork it. The things people can do are endless. Even now I just thought about using

Re: [gentoo-dev] Re: Add Hooks to Eselect

On Mon, Aug 21, 2023, 08:15 Duncan, <1i5t5.dun...@cox.net> wrote: > Suggestion: A more flexible approach would make pre/post directories, > Or allow both file and directories. > do [[ > # maybe skip either the executable or README test? > # or perhaps only match

Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch

On Mon, Jul 17, 2023, 22:53 Ulrich Mueller, wrote: > >>>>> On Mon, 17 Jul 2023, Matt Turner wrote: > > > From: konsolebox > > Closes: https://bugs.gentoo.org/841392 > > Signed-off-by: Matt Turner > > Maybe the commit message could shortly explain w

Re: [gentoo-portage-dev] [PATCH] Disarm FEATURES=distcc-pump

ll just rebuild your system without distcc-pump to make a valid bug report." is very agreeable to me. -- konsolebox

Re: [gentoo-portage-dev] [PATCH] Disarm FEATURES=distcc-pump

o fix whatever needs to be fixed on this, it would need another request to put the feature back, which I find would be very hard to be granted. I also agree that making specific packages use RESTRICT is more appropriate. -- konsolebox

Re: [gentoo-dev] rfc: moving default location of portage tree

On Fri, Jul 13, 2018 at 5:15 PM, Ulrich Mueller wrote: >>>>>> On Fri, 13 Jul 2018, konsolebox wrote: > >> I don't mind calling ::gentoo as Gentoo's official ebuild repository, >> but it also has been "a portage tree", and "the portage tree" b

Re: [gentoo-dev] rfc: moving default location of portage tree

lt path. > > -- > Brian Dolbec I don't mind calling ::gentoo as Gentoo's official ebuild repository, but it also has been "a portage tree", and "the portage tree" by default context. If you imply that people should change convention to something more PMS friendly, be explicit, and perhaps make it official, and the let them decide for themselves. Be fair at reminding that it has been there, but it's better be changed for PMS's sake. Don't make it look like the usage has always been wrong. -- konsolebox

Re: [gentoo-dev] rfc: moving default location of portage tree

n. (Or /var/lib/gentoo/repos/gentoo if you care about PMS diplomacy.) People can just move it somewhere and/or use symbolic links if they want to use a different path. Besides having /var/lib/gentoo/portage being set as "PORTDIR", I also have DISTDIR=/var/lib/gentoo/distfiles and PKGDIR=/var/lib/gentoo/packages. -- konsolebox

Re: [gentoo-dev] rfc: moving default location of portage tree

I have /var/lib/gentoo/portage defined in repos.conf/gentoo.conf. On Fri, Jul 13, 2018, 2:50 AM Raymond Jennings wrote: > In that case, I vote for /var/cache/portage, since that's literally > what purpose it serves. Namely, the cache of the gentoo infra's > current copy of teh portage tree. >

Re: [gentoo-dev] tinfo flag

On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny <mgo...@gentoo.org> wrote: > On Wed, 7 Dec 2016 16:16:45 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny <mgo...@gentoo.org> wrote: >> > On Tue, 6 Dec 201

Re: [gentoo-dev] tinfo flag

chał Górny <mgo...@gentoo.org> wrote: >> > > On Tue, 6 Dec 2016 12:54:26 -0500 >> > > Mike Gilbert <flop...@gentoo.org> wrote: >> > > >> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <konsole...@gmail.com> wrote: >>

Re: [gentoo-dev] tinfo flag

n `export` is effectively better in this context. -- konsolebox

Re: [gentoo-dev] tinfo flag

On Wed, Dec 7, 2016 at 2:17 AM, Mike Gilbert <flop...@gentoo.org> wrote: > On Tue, Dec 6, 2016 at 1:05 PM, konsolebox <konsole...@gmail.com> wrote: >> On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert <flop...@gentoo.org> wrote: >>> On Mon, Dec 5, 2016 at 6:13

Re: [gentoo-dev] tinfo flag

On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert <flop...@gentoo.org> wrote: > On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <konsole...@gmail.com> wrote: >> Please consider promoting the use of tinfo flag in packages that >> depend on sys-libs/ncurses so that they would synch

Re: [gentoo-dev] tinfo flag

On Wed, Dec 7, 2016 at 1:12 AM, Ian Stakenvicius <a...@gentoo.org> wrote: > On 05/12/16 06:13 AM, konsolebox wrote: >> Hi, >> >> Please consider promoting the use of tinfo flag in packages that >> depend on sys-libs/ncurses so that they would synchronize proper

[gentoo-dev] Re: [gentoo-project] Cross Post due to technical component - Thanks for all the fish

y the > community is very insular and unwelcoming to new comers. I sense that some people are more worried about their own merits, than solutions. -- konsolebox

[gentoo-dev] tinfo flag

ompiled. This is better than hard-coded dynamic workarounds. -- konsolebox

Re: [gentoo-dev] [RFC] New version constraints: variant one

On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric <ken...@gentoo.org> wrote: > On Mon, 5 Dec 2016 01:21:34 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> Well that's just it: ease of use and simplicity vs. portability with >> possible new parameter type

Re: [gentoo-dev] [RFC] New version constraints: variant one

On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Thu, 1 Dec 2016 14:53:51 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> I got similar idea here, but my version is that you don't have to use >> u: or v: > > The entire

Re: [gentoo-dev] [RFC] New version constraints: variant one

any. dev-foo[>=3,foo] So this time instead of using () for versions and [] for use flags, we can just have [] for both. Of course this again requires that independent and rearrangeable version elements be implemented. -- konsolebox

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On Wed, Nov 30, 2016 at 8:35 PM, Mike Gilbert <flop...@gentoo.org> wrote: > On Wed, Nov 30, 2016 at 7:11 AM, konsolebox <konsole...@gmail.com> wrote: >>>> I also prefer some things this way: >>>> >>>> - Indent the contents of the first `if` bl

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

On 11/30/16, Mike Gilbert <flop...@gentoo.org> wrote: > On Wed, Nov 30, 2016 at 3:38 AM, konsolebox <konsole...@gmail.com> wrote: >> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false >> condition, and it doesn't show an error message. I would be h

Re: [gentoo-dev] new eclass: tmpfiles.eclass round 4

of indents at minimum when the block is used recursively. - The subject word in the case block does not have to be quoted. - Always keep blocks isolated from adjacent lines. -- konsolebox tmpfiles.eclass Description: Binary data

Re: [gentoo-dev] [RFC] New version constraints: variant one

g the revision part. > They must be followed by a valid version with no revision part. > Additionally, the == and != operators can accept a version followed by > * to indicate prefix match. > > The following revision-oriented version comparison operators are > provided: > > === exact version+revision match > !== exact version+revision non-match > <== version+revision less or equal to match > >== version+revision greater or equal to match I doubted this at first but after further examination I found that it's actually more consistent. It's more aggressive but it's a more correct solution. -- konsolebox

Re: [gentoo-dev] RFC: Future EAPI version operator changes

g the [use] block to be >> more re-arrangeable in the sense that it can be used more than once >> and that it can be allowed inside condition blocks, but so far it >> really looks doable, and we could drop the restrictions. This would >> be possible along with having everything changed to independent >> conditional elements. > > 'I never really thought' is the core problem. When you want to change > PMS, you really have to think about everything. Otherwise, you end up > with screwups like := in || (). Well I'm also the type who tries to consider everything, but this was more of a blind spot, and a little bit of a different context that you can't think about quickly. I also just thought that everyone would feel conservative towards it, so I was just being careful, but I actually like the idea of including [use] blocks in the change. -- konsolebox

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny <mgo...@gentoo.org> wrote: > On Wed, 9 Nov 2016 14:32:33 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgo...@gentoo.org> wrote: >> >>dev-foo/bar{:1.3 :1

Re: [gentoo-dev] RFC: Future EAPI version operator changes

the > package name I guess. It can actually be allowed to be placed anywhere if we don't use [] for condition grouping, and just use it for the use block. -- konsolebox

Re: [gentoo-dev] RFC: Future EAPI version operator changes

: dev-foo/bar(condtion & condtion | condition) and it becomes unclear what comes first before another. The current DEPEND and RDEPEND syntax avoids it by having && and || placed outside of the block. And if you look at it, () is just synonymous to '&& ( ... )', and {} is just synonymous to '|| ( ... )'. -- konsolebox

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 8 listopada 2016 09:17:11 CET, konsolebox <konsole...@gmail.com> > napisał(a): >>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsole...@gmail.com> >>wrote: >>> On S

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On Tue, Nov 8, 2016 at 6:28 PM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 8 listopada 2016 08:09:55 CET, konsolebox <konsole...@gmail.com> > napisał(a): >>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgo...@gentoo.org> wrote: >>> Hi, everyone. >&g

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On Tue, Nov 8, 2016 at 3:09 PM, konsolebox <konsole...@gmail.com> wrote: > On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgo...@gentoo.org> wrote: >> Hi, everyone. >> >> Following my previous RFC wrt version operator problems, I'd like to >> start the second

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > On 08/11/16 07:09, konsolebox wrote: >> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgo...@gentoo.org> wrote: >>> Hi, everyone. >>> >>> Following my previous RFC wrt

Re: [gentoo-dev] RFC: Future EAPI version operator changes

inside {} are processed with OR: dev-foo/bar[>=1.3&<1.5]dev-foo/bar(>=1.3 <1.5) dev-foo/bar[>=1.3&<1.5&!=1.4.1]dev-foo/bar(>=1.3 <1.5 !=1.4.1) dev-foo/bar[<1.1|>=1.5]dev-foo/bar{<1.1 >=1.5} dev-foo/bar[=1.1*|=1.3*|>=1.5]dev-foo/bar{=1.1* =1.3* >=1.5} I find it more readable. The former looks too compressed. -- konsolebox

Re: [gentoo-dev] New portage git sync behavior

On Thu, Oct 13, 2016 at 2:51 AM, Mike Gilbert <flop...@gentoo.org> wrote: > You may direct any complaints to the Portage dev team. I only intended to notify. -- konsolebox

Re: [gentoo-dev] New portage git sync behavior

On Thu, Oct 13, 2016 at 9:36 AM, Daniel Campbell <z...@gentoo.org> wrote: > On 10/12/2016 11:45 AM, konsolebox wrote: >> On Wed, Sep 21, 2016 at 11:02 AM, Mike Gilbert <flop...@gentoo.org> wrote: >>> Portage 2.3.1 changes the default behavior for git repositories

Re: [gentoo-dev] New portage git sync behavior

ng > sync-depth = 0. > > If you have accidentally converted your development tree into a > shallow repository, you can undo the damage by running git fetch > --unshallow. > I can't find this in the release notes. -- konsolebox

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

hat sets XDG_RUNTIME_DIR? It's pam_ck_connector.so. Also see https://bugs.gentoo.org/show_bug.cgi?id=588840 for details. -- konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

On Mon, Oct 3, 2016 at 3:09 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Mon, 3 Oct 2016 14:37:15 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> But anyway, what do you think about just enabling >> IUSE="+system-readline" by default t

Re: [gentoo-dev] bash-4.4 - call for testers

ng it with a pre-release version of bash? I believe we can both agree on that idea. -- konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

On Mon, Oct 3, 2016 at 1:37 PM, konsolebox <konsole...@gmail.com> wrote: > I created another example for this. I mistakenly renamed --with-installed-readline to --with-system-readline there, sorry. Here's the correct one. -- konsolebox bash-4.4-r1.ebuild Description: Binary data

Re: [gentoo-dev] bash-4.4 - call for testers

for the targetted version of bash, which may happen in alpha or beta versions; not to mention (and 9), which I believe should be easy to implement now after this. -- konsolebox bash-4.4-r1.ebuild Description: Binary data

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, Oct 2, 2016 at 7:42 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Sun, 2 Oct 2016 18:18:17 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> I should also add that a dynamic "default" that varies depending on >> the version doesn't soun

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, Oct 2, 2016 at 6:00 PM, konsolebox <konsole...@gmail.com> wrote: > On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric <ken...@gentoo.org> wrote: >> On Sun, 2 Oct 2016 16:03:11 +0800 >> konsolebox <konsole...@gmail.com> wrote: >> >>> I actua

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Sun, 2 Oct 2016 16:03:11 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> I actually don't like the idea of enabling or disabling >> "installed-readline" based on the `${P

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, Oct 2, 2016 at 1:40 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Sun, 2 Oct 2016 13:28:04 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> I guess that's another good way to solve the readline issue (when it >> comes to bash). But I'd prefer

Re: [gentoo-dev] bash-4.4 - call for testers

On Sun, Oct 2, 2016 at 1:28 PM, konsolebox <konsole...@gmail.com> wrote: > On Sun, Oct 2, 2016 at 12:34 AM, Dan Douglas <orm...@gmail.com> wrote: >> I'd be perfectly happy requiring bundled readline when USE="readline" >> for bash versions incompatible wit

Re: [gentoo-dev] bash-4.4 - call for testers

e versions. > I rarely if ever use > interactive mode with anything other than my system default /bin/bash. I do, though. My application uses `read -e`. (That's not interactive mode I know, but it still uses readline.) -- konsolebox bash-4.4.ebuild Description: Binary data

Re: [gentoo-dev] bash-4.4 - call for testers

packages that depend on it to be rebuilt as well. If bash and readline become multi-slotted (or shared if there's a difference), it would be easier to test them. Other stuff would also not need to be rebuilt immediately. -- konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

On Sat, Oct 1, 2016 at 8:38 AM, Kent Fredric <ken...@gentoo.org> wrote: > On Sat, 1 Oct 2016 01:49:56 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> It would be nice to have some eselect command to >> easily switch from one version of Bash to another; probab

Re: [gentoo-dev] bash-4.4 - call for testers

4.3 and 4.4, not 0 and 1. And then 5.0 for the next development version, or just . -- konsolebox

Re: [gentoo-dev] bash-4.4 - call for testers

closely monitor the development of Bash. It would be nice to have some eselect command to easily switch from one version of Bash to another; probably something close to how it's done in dev-lang/ruby. -- konsolebox

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

want to; just not anything with explicit collaboration), but whether I help or not, I already did my part. I've said enough for this thread, and things are not becoming fruitful, as expected. I'm out. -- konsolebox

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

On Sat, Jun 11, 2016 at 10:48 PM, james <gar...@verizon.net> wrote: > On 06/10/2016 10:09 PM, konsolebox wrote: >> >> What matters is the contribution, and the result. If you don't like >> how a user makes a contribution, don't accept the pull request, or >>

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny <mgo...@gentoo.org> wrote: > On Sat, 11 Jun 2016 11:09:39 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> On Wed, Jun 8, 2016 at 11:53 PM, james <gar...@verizon.net> wrote: >> > The grandiose-ness you pro

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

, and a lot of users don't intend to become an official dev anyway. Besides, people can still become an official dev on later time if they would want to, or they can be persuaded to become one. --- konsolebox

Re: [gentoo-dev] What are eblits?

. The core functions also seem stable, besides some parts which aren't quoted, although commonly normal in ebuilds. This is all about loading common functions to your ebuilds, and there's nothing really dangerous in it. -- konsolebox

[gentoo-dev] Add sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf

Hi, I can't find a way to make `emerge --sync` add an option like `-f` to `git pull` when it runs it. How about adding sync-git-extra-opts or sync-git-pull-extra-opts to repos.conf? We already have sync-rsync-extra-opts for rsync so I think it's fair to add one for git. -- konsolebox

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sat, Sep 19, 2015 at 10:54 PM, Michał Górny <mgo...@gentoo.org> wrote: > Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456 > > Dnia 19 września 2015 14:59:35 CEST, konsolebox <konsole...@gmail.com> > napisał(a): >>On Sat, Sep 19, 2015

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sun, Sep 20, 2015 at 4:47 PM, Michał Górny wrote: >> >>So what would pkg-1.4_alpha1_p20 look like if you convert it to a form >> >>that uses ~? >> > >> > You shouldn't start with old gentoo version but with whatever upstream >> > uses. The goal is that the scheme is really

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 2015-09-19, o godz. 03:50:52 > konsolebox <konsole...@gmail.com> napisał(a): > >> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny <mgo...@gentoo.org> wrote: >> > And similarly

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sat, Sep 19, 2015 at 3:43 PM, konsolebox <konsole...@gmail.com> wrote: > On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgo...@gentoo.org> wrote: >> And to save you some time reading: the rpm implementation is simpler >> and more flexible. It's free of stupidities lik

[gentoo-dev] JFYIOR: A Simple Package Versioning Spec

This is what an ideal and simple versioning spec should look like to me. (Not the form, but the concept). I'm posting this here so it could be used as an added reference to anyone that would consider revising the current specification. Note: Assigning default values can be bypassed depending on

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode wrote: > Are you stating this is for package epochs? I'm sorry but I'm not familiar with the term. If you mean package versions, yes. The current specification I also mentioned is this:

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sat, Sep 19, 2015 at 2:58 AM, Matthew Thode <prometheanf...@gentoo.org> wrote: > On 09/18/2015 01:24 PM, konsolebox wrote: >> On Fri, Sep 18, 2015 at 11:38 PM, Matthew Thode >> <prometheanf...@gentoo.org> wrote: >>> Are you stating this is for pac

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov <ci...@gentoo.org> wrote: > On Fri, 18 Sep 2015 23:16:43 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> If you avoid trying to adopt versioning practices which are far from >> practical and very

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On Fri, Sep 18, 2015 at 10:01 PM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Fri, 18 Sep 2015 17:32:15 +0800 > konsolebox <konsole...@gmail.com> wrote: >> This is what an ideal and simple versioning spec should look like to >> me. > > Versio

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Wed, Sep 16, 2015 at 3:29 PM, konsolebox <konsole...@gmail.com> wrote: > On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller <u...@gentoo.org> wrote: >>>>>>> On Tue, 15 Sep 2015, Ulrich Mueller wrote: >> >>>>> We consider 5.01 and 5.010 as

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller wrote: >> On Tue, 15 Sep 2015, Ulrich Mueller wrote: > We consider 5.01 and 5.010 as equal versions. > >>> And do we still plan to keep them equal when we fix =*? > >> Yes. Makes me wonder. Are there even packages that

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 8:18 PM, Ciaran McCreesh wrote: > Semantic versioning is a new fad. I believe it's already been there for a while. It just didn't become a standard soon. > Certain upstreams still think that > 5.10 is a lower version that 5.2. Perl used

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 3:26 PM, konsolebox <konsole...@gmail.com> wrote: > Subslots are only applicable when creating ebuilds. Sorry I have to correct this. They are also applicable to other areas but not always sensible to use.

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 9:53 PM, Manuel Rüger wrote: > 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= =cat/foo-xyz+ is only one of the forms (we can

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 2:07 AM, Paweł Hajdan, Jr. <phajdan...@gentoo.org> wrote: > On 9/14/15 9:13 AM, konsolebox wrote: >> On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. >> <phajdan...@gentoo.org> wrote: >>> On 9/14/15 6:35 AM, konsolebox wrote: >>&g

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 2:12 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/14/2015 06:35 AM, konsolebox wrote: >> So my suggestion is to add ~> as another operator. With it we can >> have

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Tue, Sep 15, 2015 at 4:38 PM, Ulrich Mueller wrote: > We consider 5.01 and 5.010 as equal versions. And do we still plan to keep them equal when we fix =*? Would that mean 5.1 is the same as 5.10? That's clearly illegal to what most versioning schemes packages follow

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. <phajdan...@gentoo.org> 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,

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

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.

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 1:38 PM, Daniel Campbell wrote: > Honestly, this situation looks like a perfect candidate for slotting > instead of adding a new feature. If SLOT is setup correctly between > ebuilds, you could check to be sure it's a specific SLOT. So in your > case,

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 2:19 PM, Kent Fredric <kentfred...@gmail.com> wrote: > On 14 September 2015 at 18:09, konsolebox <konsole...@gmail.com> wrote: >> Because they could also match pkg-1.0.2aa > > That would imply > > =pkg-1.0.2* would match 1.0.20 > &g

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 4:32 PM, konsolebox <konsole...@gmail.com> wrote: > On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric <kentfred...@gmail.com> wrote: >> On 14 September 2015 at 20:22, konsolebox <konsole...@gmail.com> wrote: >>> If we use an arithme

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 <u...@gentoo.org> wrote: >>> Sorry, but I don't get it. How would these b

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

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric <kentfred...@gmail.com> wrote: > On 14 September 2015 at 20:22, konsolebox <konsole...@gmail.com> wrote: >> If we use an arithmetic operator like ~> then that could be decided > > As a counter proposal I'd suggest a d