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 isn&#
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
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
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
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 tr
new default 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
b/gentoo/portage then. (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
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.
>
>
On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny wrote:
> On Wed, 7 Dec 2016 16:16:45 +0800
> konsolebox wrote:
>
>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny wrote:
>> > On Tue, 6 Dec 2016 20:11:34 -0600
>> > William Hubbs wrote:
>> >
>> &
6 12:54:26 -0500
>> > > Mike Gilbert wrote:
>> > >
>> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox wrote:
>> > >> > Please consider promoting the use of tinfo flag in packages that
>> > >> > depend on sys-libs/ncurses
`export` is effectively better
in this context.
--
konsolebox
On Wed, Dec 7, 2016 at 2:17 AM, Mike Gilbert wrote:
> On Tue, Dec 6, 2016 at 1:05 PM, konsolebox wrote:
>> On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert wrote:
>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox wrote:
>>>> Please consider promoting the use of tinfo fla
On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert wrote:
> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox wrote:
>> Please consider promoting the use of tinfo flag in packages that
>> depend on sys-libs/ncurses so that they would synchronize properly
>> with sys-libs/ncurses[tinfo
On Wed, Dec 7, 2016 at 1:12 AM, Ian Stakenvicius 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 properly
>> with sys-libs/
and unwelcoming to new comers.
I sense that some people are more worried about their own merits, than
solutions.
--
konsolebox
ompiled. This is better than hard-coded dynamic workarounds.
--
konsolebox
On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric wrote:
> On Mon, 5 Dec 2016 01:21:34 +0800
> konsolebox wrote:
>
>> Well that's just it: ease of use and simplicity vs. portability with
>> possible new parameter types in the future; your pick. I'll
>> p
On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric wrote:
> On Thu, 1 Dec 2016 14:53:51 +0800
> konsolebox wrote:
>
>> I got similar idea here, but my version is that you don't have to use
>> u: or v:
>
> The entire point of defining it as a prefix-space was to avoid
y.
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
On Wed, Nov 30, 2016 at 8:35 PM, Mike Gilbert wrote:
> On Wed, Nov 30, 2016 at 7:11 AM, konsolebox wrote:
>>>> I also prefer some things this way:
>>>>
>>>> - Indent the contents of the first `if` block for consistency's sake,
>>>> and
On 11/30/16, Mike Gilbert wrote:
> On Wed, Nov 30, 2016 at 3:38 AM, konsolebox wrote:
>> - `[[ ${ROOT} == / ]] || return 0` seems to present a harmless false
>> condition, and it doesn't show an error message. I would be helpful
>> to have a comment added above it t
, and it makes the use 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
sions ignoring 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
gt; dev-foo/bar[foo][bar]
>>
>> Again, I never really thought about allowing 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
On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny wrote:
> On Wed, 9 Nov 2016 14:32:33 +0800
> konsolebox wrote:
>
>> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny wrote:
>> >>dev-foo/bar{:1.3 :1.4 :1.5} ## Solves "A. Range dependencies vs
>> >>slotting&q
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
v-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
On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny wrote:
> Dnia 8 listopada 2016 09:17:11 CET, konsolebox
> napisał(a):
>>On Tue, Nov 8, 2016 at 3:09 PM, konsolebox
>>wrote:
>>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny
>>wrote:
>>>> Hi, everyone.
&g
On Tue, Nov 8, 2016 at 6:28 PM, Michał Górny wrote:
> Dnia 8 listopada 2016 08:09:55 CET, konsolebox
> napisał(a):
>>On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> Following my previous RFC wrt version operator problems, I
On Tue, Nov 8, 2016 at 3:09 PM, konsolebox wrote:
> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny wrote:
>> Hi, everyone.
>>
>> Following my previous RFC wrt version operator problems, I'd like to
>> start the second part of the discussion: how to improve versi
On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt wrote:
> On 08/11/16 07:09, konsolebox wrote:
>> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny wrote:
>>> Hi, everyone.
>>>
>>> Following my previous RFC wrt version operator problems, I'd like to
>>&g
ns placed 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
On Thu, Oct 13, 2016 at 2:51 AM, Mike Gilbert wrote:
> You may direct any complaints to the Portage dev team.
I only intended to notify.
--
konsolebox
On Thu, Oct 13, 2016 at 9:36 AM, Daniel Campbell wrote:
> On 10/12/2016 11:45 AM, konsolebox wrote:
>> On Wed, Sep 21, 2016 at 11:02 AM, Mike Gilbert wrote:
>>> Portage 2.3.1 changes the default behavior for git repositories to
>>> sync with a depth of 1. If you are us
;
> 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
_connector.so. Also see
https://bugs.gentoo.org/show_bug.cgi?id=588840 for details.
--
konsolebox
On Mon, Oct 3, 2016 at 3:09 PM, Kent Fredric wrote:
> On Mon, 3 Oct 2016 14:37:15 +0800
> konsolebox wrote:
>
>> But anyway, what do you think about just enabling
>> IUSE="+system-readline" by default to any version, and just rely on
>> KEYWORDS=""
version of bash? I believe we can both agree on that idea.
--
konsolebox
On Mon, Oct 3, 2016 at 1:37 PM, konsolebox 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
no counter-package of readline 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
On Sun, Oct 2, 2016 at 7:42 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 18:18:17 +0800
> konsolebox wrote:
>
>> I should also add that a dynamic "default" that varies depending on
>> the version doesn't sound good to me. For one at least, it confuses
>
On Sun, Oct 2, 2016 at 6:00 PM, konsolebox wrote:
> On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric wrote:
>> On Sun, 2 Oct 2016 16:03:11 +0800
>> konsolebox wrote:
>>
>>> I actually don't like the idea of enabling or disabling
>>> "installed-readl
On Sun, Oct 2, 2016 at 4:58 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 16:03:11 +0800
> konsolebox wrote:
>
>> I actually don't like the idea of enabling or disabling
>> "installed-readline" based on the `${PV} != *_rc*` condition. If a
>> user
On Sun, Oct 2, 2016 at 1:40 PM, Kent Fredric wrote:
> On Sun, 2 Oct 2016 13:28:04 +0800
> konsolebox wrote:
>
>> I guess that's another good way to solve the readline issue (when it
>> comes to bash). But I'd prefer that it's not done automatically.
>&g
On Sun, Oct 2, 2016 at 1:28 PM, konsolebox wrote:
> On Sun, Oct 2, 2016 at 12:34 AM, Dan Douglas wrote:
>> I'd be perfectly happy requiring bundled readline when USE="readline"
>> for bash versions incompatible with the installed readline,
>
> I guess
uot; for those 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
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
On Sat, Oct 1, 2016 at 8:38 AM, Kent Fredric wrote:
> On Sat, 1 Oct 2016 01:49:56 +0800
> konsolebox wrote:
>
>> 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 don
en 5.0 for the next
development version, or just 9999.
--
konsolebox
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
e some suggestions
when I 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
On Sat, Jun 11, 2016 at 10:48 PM, james 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
>> don't merge his
On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny wrote:
> On Sat, 11 Jun 2016 11:09:39 +0800
> konsolebox wrote:
>
>> On Wed, Jun 8, 2016 at 11:53 PM, james wrote:
>> > The grandiose-ness you propose should only come upon graduating from proxy
>> > school, imho.
t adds more activity, 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
for me. I avoid projects where
collaboration is mandatory. I prefer contributing to a project with
open and loosely knit arrangements, and a dynamic system. Rankings,
team bonding mean nothing.
---
konsolebox
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
On Sat, Jan 23, 2016 at 4:27 AM, Brian Dolbec wrote:
> On Sat, 23 Jan 2016 03:45:14 +0800
> konsolebox wrote:
>
>> On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec
>> wrote:
>> > On Sat, 23 Jan 2016 01:05:12 +0800
>> > konsolebox wrote:
>> >
>&
On Sat, Jan 23, 2016 at 2:05 AM, Brian Dolbec wrote:
> On Sat, 23 Jan 2016 01:05:12 +0800
> konsolebox wrote:
>
>> On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> > konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as excerpted:
>&g
On Fri, Jan 22, 2016 at 11:30 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> konsolebox posted on Fri, 22 Jan 2016 22:10:53 +0800 as excerpted:
>
>> 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 s
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
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 upstream friendly.
>
On Sat, Sep 19, 2015 at 10:54 PM, Michał Górny 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
> napisał(a):
>>On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny
>>wrote:
>>&g
On Sat, Sep 19, 2015 at 3:43 PM, konsolebox wrote:
> On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny wrote:
>> And to save you some time reading: the rpm implementation is simpler
>> and more flexible. It's free of stupidities like hardcoded suffix
>> lists or forced co
On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny wrote:
> Dnia 2015-09-19, o godz. 03:50:52
> konsolebox napisał(a):
>
>> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny wrote:
>> > And similarly to the current solution it's full of silly special cases and
>>
On Sat, Sep 19, 2015 at 4:11 AM, Vladimir Smirnov wrote:
> On Fri, 18 Sep 2015 23:16:43 +0800
> konsolebox wrote:
>
>> If you avoid trying to adopt versioning practices which are far from
>> practical and very far from common it is (as proven by the example
>> code
On Sat, Sep 19, 2015 at 2:58 AM, Matthew Thode
wrote:
> On 09/18/2015 01:24 PM, konsolebox wrote:
>> 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 t
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:
https://projects.gentoo.org/pms/5/pms.html#x1-280003.2
On Fri, Sep 18, 2015 at 10:01 PM, Ciaran McCreesh
wrote:
> On Fri, 18 Sep 2015 17:32:15 +0800
> konsolebox wrote:
>> This is what an ideal and simple versioning spec should look like to
>> me.
>
> Versioning isn't ideal and simple.
If you avoid trying to adopt versi
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
On Wed, Sep 16, 2015 at 3:29 PM, konsolebox wrote:
> 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
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 to be notorious for doing
> this,
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 still follow this
fo
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 including the semantic
v
On Tue, Sep 15, 2015 at 3:26 PM, konsolebox 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.
On Tue, Sep 15, 2015 at 2:12 AM, Kristian Fiskerstrand 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 an expression like &#x
On Tue, Sep 15, 2015 at 2:07 AM, Paweł Hajdan, Jr.
wrote:
> 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:
&
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 still consider ~> or
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 propos
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
> "*" inst
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
>=
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 fr
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 acc
On Mon, Sep 14, 2015 at 2:19 PM, Kent Fredric wrote:
> On 14 September 2015 at 18:09, konsolebox wrote:
>> Because they could also match pkg-1.0.2aa
>
> That would imply
>
> =pkg-1.0.2* would match 1.0.20
>
> When it only matches 1.0.2 and 1.0.2.*
>
> You're
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, pkg-1.0.2[a-z] would b
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.
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 equiv
86 matches
Mail list logo
