Re: [gentoo-dev] Add Hooks to Eselect

[konsolebox]

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't what eselect modules were designed for. They are specialised
> tools that are supposed to do one thing, and one thing only.


So let's say modules weren't initially designed to be extensive.  What's
stopping those from becoming one now?  Tradition?

It's like
> suggesting that a command like cat or mv would need configuration or
> some extension mechanism.
>

Bad comparison and a stretch.

Also, given that eselect modules are normally run as root and the damage
> that can result from bugs, I'd rather keep things simple, instead of
> introducing "endless" possibilities. This approach has worked very well
> during the last 18 years.
>

And when I said unnecessary restriction this was it.  You're trying to
restrict what users can do in a free system like Gentoo because they might
damage their system which is ridiculous.

If you want to keep things simple for yourself don't touch
/etc/eselect/hooks.

And if you think third party code might abuse it, QA it.  Or maybe just
make eselect read /usr/local/etc/eselect/hooks instead.


> (If anything, a hook mechanism would look very different from what was
> proposed here. First, changing a low-level function like check_do() is
> really a no-no, because this function is documented in the eselect
> developer guide and third-party modules may rely on it. Second, instead
> of executing a separate script for every hook, there would be a file
> defining shell functions for all subactions of a given module. But I
> haven't thought about any details, because as I said, I don't see much
> incentive for such a thing.)
>

I just checked.  Check_do is currently documented to be only used
internally so no modules should use it but if you really think check_do
shouldn't be modified then the answer is simple.  Just make the function
that calls the hooks the wrapper instead.

As for declaring functions to represent as hooks yes I thought about that
but that's a terrible idea.  Not only is it hard to declare declaratively
it also taints eselect's environment.

Come think of it, hooks should be source'd from a subshell.  I.e., "(
source ... )".

>

Re: [gentoo-dev] Add Hooks to Eselect

[konsolebox]

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 it to auto update Ruby shebangs in $HOME/bin in a
manner that stubs are consistent with existing user gems for the newly
selected version.  I wouldn't need to wait for Gentoo Ruby to change
anything.

If there was, it would have been suggested previously since eselect was
> created in 2005. Also, by design, eselect itself doesn't rely on any
> configuration in /etc so this would be a somewhat intrusive change.
>

Weak arguments in my opinion.  It promotes unnecessary restriction.

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

[konsolebox]

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 *.sh filenames instead
> # to reflect the in-shell sourcing?
> -x $hookfile &&
> $hookfile == ${hookfile#README} &&
> $hookfile == ${hookfile#.} &&
> $hookfile == ${hookfile%.bak} &&
> $hookfile == ${hookfile%\~}
> ]] && source "$hookfile"
> done
>

Just checking if file has +x is better.  Easier to disable scripts that
way.

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

[konsolebox]

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 why this is needed,
> or what problem is fixed by it?
>

It silences the default branch warning. If that's unwanted, kindly just
close the issue.

>

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

[konsolebox]

On Tue, Jul 17, 2018 at 11:28 PM Michał Górny  wrote:
>
> Sure, provided that they are warned that any suspicious bug reports will
> be rejected.  Developers have better things to do than try to figure out
> whether some unmaintained-for-years, half-broken feature may have been
> the cause of a misbehaving system.

Yes, even a strong warning like "Warning: Usage of distcc-pump can
lead to broken builds. Any bug report that involves a package or a
package dependency of any level that is compiled with the use of
distcc-pump will unconditionally be rejected. You might as well 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

[konsolebox]

On Tue, Jul 17, 2018 at 4:45 AM Michał Górny  wrote:
>
> W dniu pon, 16.07.2018 o godzinie 13∶16 -0700, użytkownik Zac Medico
> napisał:
> > On 07/16/2018 02:26 AM, Michał Górny wrote:
> > > The pump mode of distcc has been causing issues for years now,
> > > and upstream does even attempt to fix it. Disarm the FEATURES so that
> > > people do not have to do that themselves after discovering all the bugs.
> > > ---
> > >  bin/phase-functions.sh | 17 -
> > >  man/make.conf.5|  5 -
> > >  pym/_emerge/EbuildPhase.py |  2 +-
> > >  3 files changed, 5 insertions(+), 19 deletions(-)
> >
> > Maybe we should simply support RESTRICT="distcc-pump" so that
> > incompatible ebuilds can disable it? I don't see that many bug reports
> > about it, and a forums search turned up this recent thread which
> > suggests that some people may be using it:
>
> I did.  There are only two reasons you don't see them often:
>
> 1. because not that many people use distcc,
>
> 2. because when they do, they quickly learn how broken it is and disable
> it.

It's been just a month and a half since I rebuilt a Gentoo system with
distcc-pump, and that system ended up running well.

I don't disable distcc-pump quickly. At least not globally. I only
disable it in packages that don't compile with it.

> RESTRICT won't be helpful because distcc-pump is also capable of silent
> miscompilations and indirect breakage.  If you used it at least once, my
> only advice is to rebuild your entire system.

I believe giving a general warning whenever distcc-pump is used is
enough. Users should be allowed to decide whether they'll use it or
not. There are users who know when to use it, and are capable of
managing build-time inconsistencies.

Saying that distcc-pump is capable of silent miscompilations and
indirect breakage I think is also an aggressive and ungrounded
presumption.

Also, if upstream suddenly decides to 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

[konsolebox]

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" 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.
>
> You may be surprised, but the word "Gentoo" doesn't even occur in the
> main part (chapters 2 to 15) of the PMS document, except for one place
> referring to "Gentoo's Catalyst tool".
>
> Calling it "Gentoo repository" instead of "Portage tree" is purely a
> matter of distro policy and has nothing to do with PMS.

PMS mentions "ebuild repository", hence "Gentoo's official ebuild
repository" vs. "Gentoo Portage Tree"; vs. "Which Portage tree do you
use?".

-- 
konsolebox

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

[konsolebox]

On Fri, Jul 13, 2018 at 3:47 AM, Brian Dolbec  wrote:
> On Thu, 12 Jul 2018 11:49:37 -0700
> 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 Thu, Jul 12, 2018 at 11:00 AM Alec Warner 
>> wrote:
>> >
>> > On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings
>> >  wrote:
>> >>
>> >> Just for the record, but would putting a setting inside
>> >> /etc/portage/make.conf be the appropriate way to handle this?
>> >>
>> >
>> > The settings already exist (and have existed for 10 years.) This
>> > bikeshed discussion is literally trying to decide what the default
>> > should be.
>> >
>> > -A
>> >
>>
>
> This is not a personal attack against you.  Just picked this one to say
> something again...
>
>
> PLEASE, PLEASE stop calling it the "portage" tree.  The repo name is
> "gentoo".  "portage is the default package manager, but not the only
> choice.  Far too often, it takes awhile to figure out what someone is
> trying to say because of that confusion between the tree and the
> package manager.
>
> PLUS, it has been decided already long ago that the directory name
> should reflect the repository name.  We have been enforcing that rule
> for overlays for a long time.  It has just been taking a long time to
> get our tooling in order so that we can change our own to follow that
> rule.
>
> So, "portage" should not be a directory name in the 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

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

[konsolebox]

On Fri, Jul 13, 2018 at 5:12 AM, William Hubbs  wrote:
> On Thu, Jul 12, 2018 at 10:13:57PM +0200, Michał Górny wrote:
>> W dniu czw, 12.07.2018 o godzinie 15∶51 -0400, użytkownik Rich Freeman
>> napisał:
>> > On Thu, Jul 12, 2018 at 3:47 PM Brian Dolbec  wrote:
>> > >
>> > > So, "portage" should not be a directory name in the new default path.
>> > >
>> >
>> > Well, in my examples I proposed it as that is the software that
>> > created the path, but then again in the spirit of PMS portage isn't
>> > the only PM.
>> >
>> > So:
>> > /var/lib/repos/gentoo ?
>> >
>>
>> Subdirectories of /var/lib should be named after the tool/package name.
>> There's no tool or package called 'repos'.
>
> Technically mgorny is correct here. FHS requires that everything under
> /var/lib be under a directory for the package or for the distro [1].
> Note the comment about packaging support in 5.8.1.
>
> Based on that this is my thought:
>
> * /var/lib/portage is for portage specific stuff -- maybe even /var/db/pkg
> in the future should go to /var/lib/portage/pkg.
>
> * /var/lib/gentoo, on the other hand, could be where repos, distfiles
> and binpkgs go.
> William
>
> [1]
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varlibVariableStateInformation

/var/lib/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

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

[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 Thu, Jul 12, 2018 at 11:00 AM Alec Warner  wrote:
> >
> > On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings 
> wrote:
> >>
> >> Just for the record, but would putting a setting inside
> >> /etc/portage/make.conf be the appropriate way to handle this?
> >>
> >
> > The settings already exist (and have existed for 10 years.) This
> bikeshed discussion is literally trying to decide what the default should
> be.
> >
> > -A
> >
>
>

Re: [gentoo-dev] tinfo flag

[konsolebox]

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 2016 20:11:34 -0600
>> > William Hubbs <willi...@gentoo.org> wrote:
>> >
>> >> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> >> > On Tue, Dec 6, 2016 at 4:15 PM, Michał 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:
>> >> > >> > 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].
>> >> > >>
>> >> > >> I would rather see the tinfo USE flag removed from ncurses.
>> >> > >
>> >> > > vapier doesn't consider this QA violation a QA violation.
>> >> > >
>> >> > > https://bugs.gentoo.org/487844
>> >> >
>> >> > Perhaps QA could take some action then?
>> >> >
>> >> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor 
>> >> > solution.
>> >>
>> >> 
>> >> Our policies are in the dev manual, so please cite the violation there.
>> >> If you can't, this is not a qa violation, so please don't call it one.
>> >> 
>> >>
>> >> I don't see a problem with the use flag and suggest updating the other 
>> >> ebuilds.
>> >
>> > The flag randomly changes ABI, breaking all reverse dependencies.
>> > Please tell me this is a good practice.
>>
>> And there you had just proven that the ncurses package is installed in
>> two modes, showing that a flag like tinfo is needed to represent them.
>> It's not the ncurses package's fault.  It's the depending packages'
>> responsibility to properly adapt to it.
>
> Packages are not intelligent beings, so they can't have responsibility.

Of course.

> Package maintainers have. You can't expect people to spend a lot of
> time updating a lot of packages every time a new ABI-breaking flag is
> suddenly introduced in a core package, if it's not even clear if it
> going to stay long-term.

So you're suggesting to wait and keep things [partly] broken until
then.  Why not fix things first then remove the [-tinfo] feature when
everything no longer needs it instead.  This is even just a one-time
solution, and is not much different with the massive number of
pkg-config patches currently being implemented among ebuilds.  (Again,
I'm not exactly liking the use of pkg-config.   I'd rather have a
simple export since it's good enough, easier to implement, less
compromising with the source, and is more universal.)

> Not to mention the USE flag will be a true PITA for our users. Just
> imagine all the conflicts when one package doesn't support
> ncurses[tinfo], or the other way around...

Better show the conflicts than allow users to "shoot themselves in the
foot" without even knowing it.  I'd rather solve those issues than
"trust" that everything would just work without knowing it, or fix a
package everytime I see a breakage.  Consistency comes first before
anything else, otherwise you're applying an incomplete solution or a
workaround.

>> Basically you're suggesting to drop either of those modes.  Now I'm
>> asking, would one of those (likely tinfo mode) be workable in all
>> packages?  Do you find that it would cause less issues than this
>> solution?  And I'm talking about end-user issues, not ebuild
>> implementation issues.
>
> Yes. If I recall correctly, libncurses links to libtinfo, so packages
> already built continue to work. Of course, new packages (including deps
> of the libraries already linked to libncurses) may fail to build.
>
> Remember that binary distros have to make a choice.

This is Gentoo.  Consider reading the first two lines in
https://gentoo.org/get-started/about/.

> I can understand
> keeping the flag to help people migrate more gracefully when building
> from source. But it's not a way to run things long-term.

Long-term about?

>> I find that forcing depending packages to follow that mode sounds
>> worse than what you claim a QA violation.
>
> Really? Because 'choice' or do you have a better argument than that?

I didn't get that.  Please be less ambiguous.

Note that I didn't imply there that I agree with your idea.  The use
of tinfo in ncurses is a correct uncompromising solution.  The one
questionable is forcing packages to work with [tinfo], because there
may be cases where it could resort to too much patching that it
already becomes a hack.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny <mgo...@gentoo.org> wrote:
> On Tue, 6 Dec 2016 20:11:34 -0600
> William Hubbs <willi...@gentoo.org> wrote:
>
>> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> > On Tue, Dec 6, 2016 at 4:15 PM, Michał 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:
>> > >> > 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].
>> > >>
>> > >> I would rather see the tinfo USE flag removed from ncurses.
>> > >
>> > > vapier doesn't consider this QA violation a QA violation.
>> > >
>> > > https://bugs.gentoo.org/487844
>> >
>> > Perhaps QA could take some action then?
>> >
>> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.
>>
>> 
>> Our policies are in the dev manual, so please cite the violation there.
>> If you can't, this is not a qa violation, so please don't call it one.
>> 
>>
>> I don't see a problem with the use flag and suggest updating the other 
>> ebuilds.
>
> The flag randomly changes ABI, breaking all reverse dependencies.
> Please tell me this is a good practice.

And there you had just proven that the ncurses package is installed in
two modes, showing that a flag like tinfo is needed to represent them.
It's not the ncurses package's fault.  It's the depending packages'
responsibility to properly adapt to it.

Basically you're suggesting to drop either of those modes.  Now I'm
asking, would one of those (likely tinfo mode) be workable in all
packages?  Do you find that it would cause less issues than this
solution?  And I'm talking about end-user issues, not ebuild
implementation issues.

I find that forcing depending packages to follow that mode sounds
worse than what you claim a QA violation.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 6:26 AM, Mike Gilbert <flop...@gentoo.org> wrote:
> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.

If it's the only consistent solution, either you go for it,
compromise, or be contented that it's half-broken.  I'm not a fan of
the latter 2.  Or maybe we can /hopefully/ wait for a non-workaround
solution in the future EAPI, which I doubt could be provided.

I'm not a developer, but I can volunteer to make some of the changes.
I'll just place the packages in a public repo.  Just promise me my
effort won't go to waste.

Doing gradual changes only for every ebuild version bump is not a bad
thing either, since that's even what is happening right now.

Maybe we can create an eclass to make some changes easier (if
applicable and useful), and/or debate whether the use of pkg-config
over a simple `use tinfo` test and an `export` is effectively better
in this context.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

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 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 synchronize properly
>>>> with sys-libs/ncurses[tinfo].
>>>
>>> I would rather see the tinfo USE flag removed from ncurses.
>>
>> There are people who use packages that rely on sys-libs/ncurses[tinfo].
>
> So we should either:
>
> 1. Always enable tinfo.
> 2. Always disable tinfo, but install a binary compatibility symlink:
>
> /lib/libtinfo.so.6 -> libncurses.so.6

If that's certain not to cause issues now or in the future, and is
workable in all depending packages, then I'm ok with it.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

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 synchronize properly
>> with sys-libs/ncurses[tinfo].
>
> I would rather see the tinfo USE flag removed from ncurses.

There are people who use packages that rely on sys-libs/ncurses[tinfo].

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

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 properly
>> with sys-libs/ncurses[tinfo].
>>
>> It could be as simple as:
>>
>> IUSE="tinfo"
>>
>> RDEPEND="sys-libs/ncurses[tinfo=]"
>>
>> pkg_setup() {
>> use tinfo && export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"
>> }
>>
>> The last line can be changed/enhanced, depending on the package.
>>
>> It helps keep binaries consistent even if sys-libs/ncurses[-tinfo]
>> gets recompiled to sys-libs/ncurses[tinfo], because they are forced to
>> be recompiled.  This is better than hard-coded dynamic workarounds.
>>
>
> Should this message perhaps have been directed to a particular set of
> developers or package maintainers rather than everyone on this list?

Sorry, I just thought it's better to send it to the list first.  I
already created a bug report for it (#601764).  It was rejected right
away for a reason not related to the main point.  I also made a reply
in #457530.

> I'm not sure what our stance is on propagating USE flags to rdeps when
> the package itself doesn't care (except due to the --libs output
> changing from pkg-config).  I feel that adding tinfo to IUSE the way
> it's suggested here might be the only technical solution right now,
> but at the same time it seems like something that might be better
> suited to something that should be addressed through other mechanisms
> in a future-EAPI...

Yes I thought a better solution can be provided in a future EAPI, like
perhaps a 
force-rebuild-everything-that-depends-on-the-package-if-flag-usage-changes,
but I'd rather not wait for it.  A new mechanism like that might also
force rebuilding of packages that don't rely on the features of
libtinfo.  An explicit declaration that a package wants tinfo like
sys-libs/ncurses[tinfo=] is better.

> Note in particular though that the pkg_setup example ISN'T imo a good
> idea -- rather, pkg-config should be used, as it will return the
> appropriate --libs output whether ncurses is built with USE=tinfo
> enabled or not.

Yes, I also said in my reply that pkg-config can be used for more accuracy.

-- 
konsolebox

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

[konsolebox]

On Wed, Dec 7, 2016 at 12:35 AM, Craig Inches <cr...@xayto.net> wrote:
> Hi,
>
> I have decided to stop involvement with the Project as a proxied
> maintainer, and to stop pursuing becoming a developer. Two main
> reasons for this, one the community is at times openly hostile on the
> mailing lists and IRC, of which I have asked people on IRC about whom
> have responded this is the norm(once in awhile vents is fine it
> happens but this has been consistently visible) this is ignoring
> cultural differences that may cause misunderstanding; Secondly 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

[konsolebox]

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/ncurses[tinfo].

It could be as simple as:

IUSE="tinfo"

RDEPEND="sys-libs/ncurses[tinfo=]"

pkg_setup() {
use tinfo && export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"
}

The last line can be changed/enhanced, depending on the package.

It helps keep binaries consistent even if sys-libs/ncurses[-tinfo]
gets recompiled to sys-libs/ncurses[tinfo], because they are forced to
be recompiled.  This is better than hard-coded dynamic workarounds.

-- 
konsolebox

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

[konsolebox]

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 types in the future; your pick.  I'll
>> personally go for the former this time.
>>
>> Also, what kind of added type of parameters would you expect that
>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>>
>> I also find that the current features are already mature enough; we're
>> just enhancing it to have better control.  I don't expect anything big
>> to be added further.
>
> Its just frustrating for me, because its not the first time I've had this
> conversation.
>
> I have some vague memory of the last time we changed dependency syntax,
> and I said then something along the lines of "hey, why not get this right so
> we don't have to have this again later"
>
> And here we are, bike shedding, debating new syntax classes without forsight.

I would love to prove this with a proof-of-concept, but I don't have
the motivation yet.  I also did it once, it wasn't helpful.

>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>
> The difference between an "operator" and an "identifier" is one of the two
> hails from a limited set of punctuation marks, and sometimes the order is
> important.
>
> For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
> the former hailed from a narrow supply of characters which people saw fit
> to use for everything, and now you have fun problems in JavaScript where
> "+" does more than one thing depending on conditions.
>
> Punctuation is powerful, but its a limited resource that serves itself
> best when used sparingly.

I agree with that, but we have to consider balancing it a bit sometimes.

-- 
konsolebox

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

[konsolebox]

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 point of defining it as a prefix-space was to avoid ambiguity,
> and leave plenty of room for other such selector prefixes.
>
> Relying on properties like "is it a number" or "is it text" is a shoddy
> heuristic.
>
> A heuristic that will fail us as soon as we want to add new features in
> our matcher syntax.
>
> Hence,
>
>[(,...)]
>
>CONSTRAINT: :(,...)
>
>
> Then instead of debates about how we can invent some "new" syntax
> where we have to constantly reinvent existing syntax to allow space
> for the new syntax, we can just define new identifiers, because we thought
> ahead about this problem and gave us wiggle room to add features.

Well that's just it: ease of use and simplicity vs. portability with
possible new parameter types in the future; your pick.  I'll
personally go for the former this time.

Also, what kind of added type of parameters would you expect that
would be conflicting with USE flags, or other operators?  Wouldn't
adding another operator be enough, and not an identifying key?

I also find that the current features are already mature enough; we're
just enhancing it to have better control.  I don't expect anything big
to be added further.

And come to think of it, a parameter with a key can be distinguished
differently from a USE flag, because a USE flag wouldn't have a colon,
so a parameter with an identifier that defines its class can still be
added if with would need it in the future.

-- 
konsolebox

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

[konsolebox]

On Fri, Nov 11, 2016 at 10:37 PM, Kent Fredric <ken...@gentoo.org> wrote:
> orrr we could do away with punctuation abuse and make "[]" be a 
> "Parameter space"
>
>
>dev-foo/bar[u:foo,v:>=3]

I got similar idea here, but my version is that you don't have to use
u: or v:.  When I was looking for the feature that 'foo[bar?]'
provides yesterday, I saw that the the special operators for use flags
don't conflict with the version operators.  And only use flags use
non-operator characters, so they could be used alone and
distinguishably without 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

[konsolebox]

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` block for consistency's sake,
>>>> and less confusion.
>>>
>>> I disagree; indenting the entire eclass is silly and does not really
>>> improve readability. Also, this is a very common pattern found in
>>> other eclasses.
>>
>> I prefer following consistency before anything else.  And it's just
>> uncommon and odd, but it's not silly.  Imagine if you use another `if`
>> block on the second level where more functions are defined.  Would you
>> also not indent that?
>
> That first "if" is a bit of a special case; it's only there to prevent
> the code from being executed more than once in global scope. This
> provides a minor speed boost when the eclass gets sourced more than
> once, and makes sure that any global variables are only set once.

OT: inherit() should have already been able to have a non-hacky
solution of making sure that eclass files are loaded only once.  Bash
4.2 has already supported global declaration of variables with -g (in
case the flag variable would need to be declared inside a function),
and associative arrays with -A.  Even older versions of Bash (<4.0)
can make use of multiple variables with a common prefix to imitate
associative arrays if compatibility is needed.  It could just check
BASH_VERSINFO if it has to downgrade to a less-efficient method.

Besides no longer having to rely on a special `if` block, it probably
would also make loading of ebuilds faster since script codes that are
referenced multiple times wouldn't have to be re-parsed again and
again by bash.  It's scary to imagine how it happens in all ebuilds
that's read in portage, but maybe repeated loading of eclass files
doesn't always happen, who knows.  (I think it's still significant
even if the dependencies are already cached.)

> I think of it as being similar to pre-processor statement you would
> find in a C header file; one does not generally indent all the code
> within a C header file, because it just introduces a big chunk of
> whitespace that does not improve code readability.

I did as well, but I'll still prefer to have it indented, because it
avoids trying to know what the last lone `fi` is for, if you haven't
seen the first `if` condition yet.  If they are indented, your mind is
automatically set to know that they are within a conditional block,
and no surprise happens.  Maybe that's not the case if people are
already used to seeing those setup, like in eclass files, but I'm not,
so it does help improve readability in my case.

To be honest I find it painful to see anything inside a block to be
not indented, no matter what the reason is.  You can say that they
look like preprocessors in C, and preprocessors don't make codes
indent, but preprocessors are not (functional) codes, and they are
naturally recognized to have their own "indentation space" or
patterns, unlike the shell's `if`.

But anyway, I think I find it understandable now, in the context of
eclass files.

-- 
konsolebox

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

[konsolebox]

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 helpful
>> to have a comment added above it to give details why.
>
> We only want to process tmpfiles for the currently running system.
>
> If ROOT is not /, it indicates we are installing the package for use
> on a different system or in a container. In either case, the tmpfiles
> would be processed upon boot when that system/container is started.
>
> I find this fairly obvious, but if William wants to document it that's
> fine.

I'm not familiar with that, and so would other scripters who would
look at the eclass.

>> I also prefer some things this way:
>>
>> - Indent the contents of the first `if` block for consistency's sake,
>> and less confusion.
>
> I disagree; indenting the entire eclass is silly and does not really
> improve readability. Also, this is a very common pattern found in
> other eclasses.

I prefer following consistency before anything else.  And it's just
uncommon and odd, but it's not silly.  Imagine if you use another `if`
block on the second level where more functions are defined.  Would you
also not indent that?

>> - Patterns in the `case` block doesn't have to be indented. This makes
>> the contents of the `case` block aligned with the contents of the
>> other blocks (`if`, `while`, etc.), and it makes the use of indents at
>> minimum when the block is used recursively.
>
> Sorry, I have no idea what you're trying to say here. Recursive blocks?

One expensive in the use of indents:

case $x in
a)
# first inner level
case $y in
1)
# second inner level
case ...
;;
2)
;;
esac
;;
b)
;;
esac

if [ "$x" = a ]; then
# first inner level
if [ "$y" = 1 ]; then
# second inner level
elif [ "$y" = 2 ]; then
:
else
:
fi
elif [ "$x" = b ]; then
:
else
:
fi

vs.

case $x in
a)
case $y in
1)
case ...
;;
2)
;;
esac
;;
b)
;;
esac

> This really feels like you're making a personal style suggestion here,
> and I personally see nothing wrong with it as-is.

Yes the second part is more personal.

-- 
konsolebox

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

[konsolebox]

There are some things I noticed in the tmpfiles_process() function:

- `type` currently also checks for functions, alias, and builtins,
besides executable files.  If that's not intended, the `-P` option
should be added.
- What happens if neither systemd-tmpfiles nor opentmpfiles is found?
- Shouldn't the function return a nonzero if an error occurs?  It
would help scripts abort.
- `[[ ${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 to give details why.

I also prefer some things this way:

- Indent the contents of the first `if` block for consistency's sake,
and less confusion.
- Patterns in the `case` block doesn't have to be indented. This makes
the contents of the `case` block aligned with the contents of the
other blocks (`if`, `while`, etc.), 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

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

[konsolebox]

On Fri, Nov 11, 2016 at 6:53 AM, Michał Górny <mgo...@gentoo.org> wrote:
> Hello, everyone.
>
> Following my earlier threads, I'd like to propose a first complete
> solution for new version restrictions for package dependencies. I
> honestly doubt it's going to be approved since it's a major change.
> Nevertheless, I think it's an interesting topic for consideration.
>
> What is included:
>
> - conjunctive version ranges,
> - revision-free and revision-oriented comparisons,
> - full set of (blocker-free) logical operators.
>
> What isn't included:
>
> - disjunctive version ranges,
> - complete lower bound problem solution,
> - extensions for prefix matching,
> - some convenience shortcuts like Ruby's ~> op.
>
>
> Backwards compatibility [recommended]
> =
>
> For backwards compatibility, package dependency specifications using
> old-style restrictions will still be accepted. Those specifications
> will retain the old behavior, and have no new features.
>
>
> New package dependency syntax
> =
>
> New-style package dependencies use the following syntax:
>
>"/"  [":" ] ["["  "]"] ["["  "]"]
>
> with  now using the following sub-syntax:
>
> [","  ...]
>
> The version restriction operator is removed from the front and all
> package dependency specifications start with the category and package
> name, followed by optional package slot. This can be followed by
> optional version restrictions and USE flag restrictions.
>
> The version constraints (if present) must *always* be placed inside
> square brackets, even for a single constraint. Each constraint starts
> with an operator followed by a version string. Multiple constraints are
> separated using "," character, and are conjunctive (AND-ed).
>
> The operators are not valid for beginning of a USE dependency string,
> therefore the version constraint can be clearly distinguished from USE
> contraints.
>
> The version and USE flag constraints are always disjoint. If both are
> present, they must be surrounded by separate pairs of brackets.
>
> Examples:
>
>   dev-foo/bar:13[foo]  # slot + USE
>   dev-foo/bar[>=3] # single version constraint
>   dev-foo/bar:4[>=4.11,<4.20]  # slot + version range
>   dev-foo/bar[>=3][foo]# version + USE

Looks like you excluded the independent rearrangeability of the
conditional elements, and the OR feature; and also, grouping being
optional where AND would be the default control operator.

Does that still allow multi-level grouping?

You can choose to have such restrictions now, but I still highly
suggest the use of () instead of [], so it would be clear that [] is
for use flags, and () is for versions.  Not only would that lessen
confusion and remove the parser's necessity to look-ahead-and-verify,
it would also make the syntax open to future improvements.

The use of comma as a separator looks good, and minimizes the
characters that the parser would have to check when checking for a new
token.

> Version restrictions
> 
>
> Each version restriction consists of an operator followed by a version
> string.
>
> The following revision-free version comparison operators are provided:
>
>  ==   exact version match, or prefix match (with *)
>  !=   exact version non-match, or prefix non-match (with *)
>  <version less than match
>  <=   version less or equal to match
>  >version greater than match
>  >=   version greater or equal to match
>
> All those operators compare on versions 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

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

[konsolebox]

t; 3. Do we allow multiple occurrences of the same type of element? I'm 
>> >> > specifically thinking of multiple disjoint USE dependency blocks.
>> >>
>> >> I'm sorry but I'm not sure what you mean there.  I hope you can give an 
>> >> example.
>> >
>> > 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

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

[konsolebox]

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.4 :1.5}  ## Solves "A. Range dependencies vs
>> >>slotting"
>> >
>> > I'm not sure about this. Slots are kinda special, especially with regard 
>> > to slot operators. Problems I see:
>> >
>> > 1. := binds to slot of newest version matching the spec. How does this 
>> > work with your spec?
>> >
>> > 2. Should we allow using := on some of the listed slots? What would happen?
>> >
>> > 3. It's asymmetric since we can't use an AND variant.
>>
>> I had to ask help from #gentoo-dev-help in order to properly
>> understand slot operators since I haven't become too familiar with
>> them so sorry for the late reply.  (Thanks to desultory and _AxS_).
>>
>> Here I find it that we could just follow the simple AND/OR rule
>> against every condition from left to right, and the interpreter would
>> just do fine.  A user may create insensible rules just like how one
>> could create meaningless codes in C, but that won't stop the compiler
>> from compiling the code, just like how this would not prevent the
>> package manager from interpreting it.  We're also free to detect
>> ambiguous rules if we want to, and warn the user, or just disallow it
>> completely.  But it's still optional and wouldn't yield a difference
>> to a stable operation.
>>
>> Examples:
>>
>> dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4=
>> :1.5=}) renders := being an "any" operator meaningless since the
>> condition requires {:1.3= :1.4= :1.5=} to also be true.  It looks
>> insensible, but it's still algorithmically correct, and can be
>> interpreted by the package manager.
>
> Wrong. It means 'any OR 1.3 OR 1.4 ...'. Making 'any' no longer mean
> 'any' in this context is confusing.

Isn't that 'any AND (1.3 OR 1.4 OR 1.5)'?  Would that make sense to
have it the other way around instead?

And when I wrote that, I already had the idea of AND being the default
control operator, and spaces being optional.

> What about {:1.3/2 :1.3/3 :1.3=}?

Left to right.  If :1.3/2 yields true, then the whole condition is
valid, next is :1.3/3, then last :1.3=.  If all is false, then the
whole condition is false.

>> dev-foo/bar(:* :=) renders :* meaningless since := restricts any
>> installed runtime dependency's slot and subslot to be currently
>> available.  It's still algorithmically correct.
>
> 'any AND newest'? Why would you ever do that? The only purpose for :*
> is to disable warnings on missing slot specifications when package has
> multiple slots.

I hope you're only arguing against the misuse, and not about whether
it's feasible when it comes to the implementation.

But anyway, "newest" is not what's being said in ebuild(5):

":= Indicates  that  any  slot value is acceptable. In addition,
for runtime dependencies, indicates that the package will break unless
a matching package with slot and sub-slot equal to the slot and
sub-slot of the best installed version at the time the package was
installed is available."

It's all about whether the currently installed runtime dependency's
current slot and sub-slot is available.  := in this case is simply
about checking that, and could only yield true or false.

Like I said I'm still new when it comes to these operators, but kindly
enlighten me so that we would know if := can be used as an independent
conditional expression or not.

Again, I don't agree with the misuse.  I just intend to give an example.

>> dev-foo/bar:={:1.3 :1.4 :1.5} OR dev-foo/bar(:= {:1.3 :1.4 :1.5})
>> implies that the currently installed package's slot and subslot should
>> be available and that the version of the slot should be 1.3, 1.4, or
>> 1.5.  The interpreter could read that condition checking from left to
>> right easily.  Is the currently installed package's slot and subslot
>> currently available?  If no, this condition renders false and the
>> currently installed package is invalid.  If yes, we follow the next
>> condition. Is the slot version any of 1.3, 1.4, or 1.5?  If yes, then
>> that condition yields true.
>
> I see a lot of added complexity here, for no benefit whatsoever.

No, it's not complex at all as everything would just be packaged in
one logical code.  I just had to explain detail by detail so I could
prove that it's doable.

The current check-if-some-specific-element-comes-before-or-after-another
which propagates ever

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

[konsolebox]

On Wed, Nov 9, 2016 at 8:30 AM, Michael Orlitzky <m...@gentoo.org> wrote:
> On 11/08/2016 10:47 AM, Michał Górny wrote:
>>
>> Strictly speaking, we don't have to since the lexing should be
>> predictable enough. Of course, mistakes like missing version following
>> the operator would result in curious errors.
>>
>> The major problem with spaces I see is that it means we end up having
>> an additional [use] block floating following them.
>>
>
> I was also thinking that the logical operators could be infix, and then
> you need the commas to avoid precedence issues with the implicit-and,
> which is written " ".

Commas and spaces can be made optional if we allow the following
tokens to be the delimiter itself.  Grouping and use of white space
can be optionally used in cases where operators would collide, most
especially after :=.

A valid package name entry also signals end of the rules for the previous entry.

Also, precedence issues and confusions can be avoid by relying on more
explicit grouping like () and {}, instead of &&, ||, & and |.

> The [use] blocks could be moved next to 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

[konsolebox]

On Tue, Nov 8, 2016 at 11:47 PM, Michał Górny <mgo...@gentoo.org> wrote:
> On Tue, 8 Nov 2016 10:39:09 -0500
> Michael Orlitzky <m...@gentoo.org> wrote:
>
>> On 11/08/2016 09:49 AM, Ulrich Mueller wrote:
>> >
>> > This wouldn't completely solve it, because we also have a := slot
>> > operator.
>>
>> Oh, duh...
>>
>>
>> > Brackets would help, or some new separator. Pick your poison:
>>
>> I would really like to have spaces around the infix operators, but then
>> we need to separate the dependencies with a delimiter (like a comma).
>
> Strictly speaking, we don't have to since the lexing should be
> predictable enough. Of course, mistakes like missing version following
> the operator would result in curious errors.
>
> The major problem with spaces I see is that it means we end up having
> an additional [use] block floating following them.

Actually after reading replies from others, I got the idea spaces can
just be made optional, if we use () and {} over & and | (and also have
&& the default function).  Any operator can be a delimiter for itself
or the previous rule:

'dev-foo/bar>=1.3<1.5' is just synonymous to 'dev-foo/bar >= 1.3 <
1.5' or 'dev-foo/bar(>=1.3 <1.5)'.  The beauty there is that it's now
starting to synchronize with the grouping syntax of DEPEND and
RDEPEND.  We would only need to add a space or use grouping if it's
necessary like after using the := operator.

[use] blocks can also be placed anywhere if we only use [] for it, and
use () and {} for grouping versions/slot/repo rules.  And if it would
help, the interpreter can now choose to just interpret/store [use]
block as another condition element with a different class (e.g. use
class) for the sake of simplicity, and restrict it to be only used
once and outside any form of grouping.

There's simplicity in there because you know [] defines flags, while
other operators define version rules.

Btw, & and | can be misused together: 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

[konsolebox]

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 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 part of the discussion: how to improve version
>>>> operators in a Future EAPI?
>>>>
>>>> I've collected various ideas on operator changes on a wiki page [1].
>>>> I've tried to stay open-minded and cover every possibility, even
>>though
>>>> I doubt some of them would be even considered.
>>>>
>>>> I should warn you that some of the solutions are interlinked to each
>>>> other, and you probably need to look through the whole page first
>>>> before starting to construct an opinion. For example, specific
>>>> solutions to most of the problems depend on whether we enable
>>version
>>>> ranges and in which form.
>>>>
>>>> I think we should start by loosely discussing the various ideas
>>>> on the wiki page. Feel free to also point out any missing ideas
>>>> or remarks that would be useful there.
>>>>
>>>> So, what are your comments?
>>>>
>>>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>>>>
>>>> --
>>>> Best regards,
>>>> Michał Górny
>>>> <http://dev.gentoo.org/~mgorny/>
>>>
>>> I also like the idea of moving the operator as it's more consistent
>>> and opens new doors to other solutions.
>>>
>>> As for the use of operator & and |, they're quite good, but I'd
>>prefer
>>> the use of Gmail's style where expressions placed in () are processed
>>> with AND, and expressions 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.
>>
>>I should also add that we can allow slots and repositories in the
>>expressions:
>>
>>dev-foo/bar{:1.3 :1.4 :1.5}  ## Solves "A. Range dependencies vs
>>slotting"
>
> I'm not sure about this. Slots are kinda special, especially with regard to 
> slot operators. Problems I see:
>
> 1. := binds to slot of newest version matching the spec. How does this work 
> with your spec?
>
> 2. Should we allow using := on some of the listed slots? What would happen?
>
> 3. It's asymmetric since we can't use an AND variant.

I had to ask help from #gentoo-dev-help in order to properly
understand slot operators since I haven't become too familiar with
them so sorry for the late reply.  (Thanks to desultory and _AxS_).

Here I find it that we could just follow the simple AND/OR rule
against every condition from left to right, and the interpreter would
just do fine.  A user may create insensible rules just like how one
could create meaningless codes in C, but that won't stop the compiler
from compiling the code, just like how this would not prevent the
package manager from interpreting it.  We're also free to detect
ambiguous rules if we want to, and warn the user, or just disallow it
completely.  But it's still optional and wouldn't yield a difference
to a stable operation.

Examples:

dev-foo/bar:={:1.3= :1.4= :1.5=} OR dev-foo/bar(:= {:1.3= :1.4=
:1.5=}) renders := being an "any" operator meaningless since the
condition requires {:1.3= :1.4= :1.5=} to also be true.  It looks
insensible, but it's still algorithmically correct, and can be
interpreted by the package manager.

dev-foo/bar(:* :=) renders :* meaningless since := restricts any
installed runtime dependency's slot and subslot to be currently
available.  It's still algorithmically correct.

dev-foo/bar{:* :=} renders := meaningless since :* would already be
true, if it becomes false, := would still be false anyway. But it's
still algorithmically correct.  In many ways, the rule doesn't make
sense at all since virtually is just boils down to be just about
dev-foo/bar, but it's not an issue that would stop the implementation
of the interpreter.  And, it's also not something that would
jeopar

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

[konsolebox]

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.
>>>
>>> Following my previous RFC wrt version operator problems, I'd like to
>>> start the second part of the discussion: how to improve version
>>> operators in a Future EAPI?
>>>
>>> I've collected various ideas on operator changes on a wiki page [1].
>>> I've tried to stay open-minded and cover every possibility, even
>>though
>>> I doubt some of them would be even considered.
>>>
>>> I should warn you that some of the solutions are interlinked to each
>>> other, and you probably need to look through the whole page first
>>> before starting to construct an opinion. For example, specific
>>> solutions to most of the problems depend on whether we enable version
>>> ranges and in which form.
>>>
>>> I think we should start by loosely discussing the various ideas
>>> on the wiki page. Feel free to also point out any missing ideas
>>> or remarks that would be useful there.
>>>
>>> So, what are your comments?
>>>
>>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>> <http://dev.gentoo.org/~mgorny/>
>>
>>I also like the idea of moving the operator as it's more consistent
>>and opens new doors to other solutions.
>>
>>As for the use of operator & and |, they're quite good, but I'd prefer
>>the use of Gmail's style where expressions placed in () are processed
>>with AND, and expressions 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.
>
> Two points here:
>
> 1. I really had no idea Gmail has anything like that, and I suspect a lot of 
> developers don't expect things to work that way either. I'm a programmer 
> though, so infix && and || are entirely obvious to me.

Yes I understand that it's new to most people that's why I'm not
really getting my hopes up on this idea. But I honestly see it as an
implementation that's easier to use in many ways.  The only difference
is how people would get used to it.  There had become a lot of
rules/operators in Portage where people had to refer to the manual in
order to understand them, and the difference between () and {} is just
a simple thing.

> 2. I don't think we are going to allow whitespace inside it. Currently 
> dependency specifications can be tokenized on whitespace (except for special 
> handling for groups). Allowing whitespace inside ranges breaks that.
>
> Furthermore, if we allows whitespace inside ranges, we should probably 
> consider allowing any whitespace in package dependency specifications, to 
> improve readability. This in turn can open a few cans of worms.

I got a bit lost there.  I hope you can give some elaborate/technical
examples about it.

-- 
konsolebox

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

[konsolebox]

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 part of the discussion: how to improve version
>> operators in a Future EAPI?
>>
>> I've collected various ideas on operator changes on a wiki page [1].
>> I've tried to stay open-minded and cover every possibility, even though
>> I doubt some of them would be even considered.
>>
>> I should warn you that some of the solutions are interlinked to each
>> other, and you probably need to look through the whole page first
>> before starting to construct an opinion. For example, specific
>> solutions to most of the problems depend on whether we enable version
>> ranges and in which form.
>>
>> I think we should start by loosely discussing the various ideas
>> on the wiki page. Feel free to also point out any missing ideas
>> or remarks that would be useful there.
>>
>> So, what are your comments?
>>
>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>>
>> --
>> Best regards,
>> Michał Górny
>> <http://dev.gentoo.org/~mgorny/>
>
> I also like the idea of moving the operator as it's more consistent
> and opens new doors to other solutions.
>
> As for the use of operator & and |, they're quite good, but I'd prefer
> the use of Gmail's style where expressions placed in () are processed
> with AND, and expressions 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.

I should also add that we can allow slots and repositories in the expressions:

dev-foo/bar{:1.3 :1.4 :1.5}  ## Solves "A. Range dependencies vs slotting"
dev-foo/bar(:1.6 {::local ::devel})  ## Especially useful in
/etc/portage/package.{keywords,mask}

Along with it, we should also drop the strict order of the slot,
version, and repo expressions (just change it to "recommended").  It
makes things more flexible and makes it easier for the parser to be
implemented.

Arithmetic ranges on the other hand should only be in the form of
being "inclusive" in both ends, and not exclusive in any.  Not only is
it simpler; it is also easier to parse.  There's also no need to use
special grouping operators like {}.  E.g. 1.3..1.5.  Grouping is only
necessary if the form would cause other possible conflicts, where in
that case (1.3..1.5) and {1.3..1.5} should just be the same, unless
there would be more added expressions in the group.

-- 
konsolebox

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

[konsolebox]

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 version operator problems, I'd like to
>>> start the second part of the discussion: how to improve version
>>> operators in a Future EAPI?
>>>
>>> I've collected various ideas on operator changes on a wiki page [1].
>>> I've tried to stay open-minded and cover every possibility, even though
>>> I doubt some of them would be even considered.
>>>
>>> I should warn you that some of the solutions are interlinked to each
>>> other, and you probably need to look through the whole page first
>>> before starting to construct an opinion. For example, specific
>>> solutions to most of the problems depend on whether we enable version
>>> ranges and in which form.
>>>
>>> I think we should start by loosely discussing the various ideas
>>> on the wiki page. Feel free to also point out any missing ideas
>>> or remarks that would be useful there.
>>>
>>> So, what are your comments?
>>>
>>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>> <http://dev.gentoo.org/~mgorny/>
>> I also like the idea of moving the operator as it's more consistent
>> and opens new doors to other solutions.
>>
>> As for the use of operator & and |, they're quite good, but I'd prefer
>> the use of Gmail's style where expressions placed in () are processed
>> with AND, and expressions 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.
>>
> Ewww, WTF should we use Google as a (bad) example?!

I don't care if it's from Google or not, and you shouldn't as well.
Grow up.  It's got nothing to do with the solution.

> And "bracketising"
> rather than explicit operators is bound to cause confusion

Subjective, and depends on the person.  I quickly adapted to it.

> and errors ...

What errors?

-- 
konsolebox

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

[konsolebox]

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 part of the discussion: how to improve version
> operators in a Future EAPI?
>
> I've collected various ideas on operator changes on a wiki page [1].
> I've tried to stay open-minded and cover every possibility, even though
> I doubt some of them would be even considered.
>
> I should warn you that some of the solutions are interlinked to each
> other, and you probably need to look through the whole page first
> before starting to construct an opinion. For example, specific
> solutions to most of the problems depend on whether we enable version
> ranges and in which form.
>
> I think we should start by loosely discussing the various ideas
> on the wiki page. Feel free to also point out any missing ideas
> or remarks that would be useful there.
>
> So, what are your comments?
>
> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

I also like the idea of moving the operator as it's more consistent
and opens new doors to other solutions.

As for the use of operator & and |, they're quite good, but I'd prefer
the use of Gmail's style where expressions placed in () are processed
with AND, and expressions 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

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

[konsolebox]

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

[konsolebox]

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 to
>>> sync with a depth of 1. If you are using a development tree with
>>> emerge --sync, you may want to override this in repos.conf by setting
>>> 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.
>>
> Wasn't it in a news message? I recall seeing it somewhere, and made the
> appropriate changes before upgrading.
>

I think you saw it here, and so did I but surprised to see that it's
not in the /usr/share/doc/portage-2.3.1 nor in 'eselect news'.

-- 
konsolebox

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

[konsolebox]

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 to
> sync with a depth of 1. If you are using a development tree with
> emerge --sync, you may want to override this in repos.conf by setting
> 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

[konsolebox]

On Wed, Oct 5, 2016 at 10:58 PM, Joakim Tjernlund
<joakim.tjernl...@infinera.com> wrote:
> Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> "(null)". This
> creates a /(null) dir. with various stuff in it.
>
> I am trying to find out what 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

[konsolebox]

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 to any version, and just rely on
>> KEYWORDS="" to prevent the user from misusing it with a pre-release
>> version of bash?  I believe we can both agree on that idea.
>
> Yeah. And at least that way if you need to prevent its use/force
> its use for any arch target you can use the USE forces.
>
> In general "less magical behaviour that tracks its version" is a good
> thing.

I created a formal request for this in
https://bugs.gentoo.org/show_bug.cgi?id=596028.

-- 
konsolebox

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

[konsolebox]

On Mon, Oct 3, 2016 at 1:53 PM, Kent Fredric <ken...@gentoo.org> wrote:
> And I get the impression that the desire you have to have different
> behaviour for non-rc versions is a bit niche.

Not quite.  I just started by siding with the current implementation
which is to disable system readline in rc versions of bash.  You're
actually the one challenging a new implementation which would allow
it.

But anyway, what do you think about just enabling
IUSE="+system-readline" by default to any version, and just rely on
KEYWORDS="" to prevent the user from misusing 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

[konsolebox]

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

[konsolebox]

I examined both RC versions of bash and readline, and it turns out
that the KEYWORDS are disabled in those.  If that is -always- the
case, we could just have IUSE='+system-readline' in any version
regardless if it's a release or not, since users would not be able to
install it anyway, unless they apply 'app-shells/bash **' to
/etc/portage/package.keywords.  If they do, then that means they're
prepared for the risk, and should know when to use the use flag.

I created another example for this.  This time, the feature can still
be disabled, but only if there is 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

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

[konsolebox]

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 sound good to me. For one at least, it confuses
>> the user.
>
> I agree that its a bit unintuitive.
>
> However, the alternatives are:
>
> - A useflag that entirely goes away depending on the version
> - A useflag that is inoperative depending on the version
>
> Neither of those are improvements.

"A useflag that entirely goes away depending on the version" (or a
flag that is implemented in one ebuild but is not on another) is
pretty common among packages and I see that as totally valid, and is
way better than a solution that uses dynamic default.

> And in both cases they're additionally messy as they require
> additional logic that changes what DEPEND is based on the version.

Doesn't look so messy to me.  My solution is pretty clean and
understandable.  It would only depend on how it is perceived by the
reading coder.  The bash ebuild was also already hacky enough.  Maybe
you're just being conservative because it doesn't always happen in
ebuilds.

>> Also, do you think there could be a helpful case that one would
>> install a non-release version of bash that compiles against the system
>> readline?  Perhaps if you're also brave enough to install an
>> pre-release version of readline to the system, there is.
>
> If this scenario was the expected scenario for non-rc releases, its only
> sensible that the development versions should be testing that usecase.
>
> If for example the development versions always only tested using their bundled
> readlines, and then the non-development versions always used dependencies,
> then testing is somewhat pointless.

Pointless for bash, or applications that depend on readline as well?
Because if it's only about bash, I see no difference.

If someone would want to try a pre-release readline, nothing would
stop him from doing it.

> Because you're no longer testing for real world problems that would be 
> possible
> due to using systemized dependenices.( ie: stipulating a new enough version,
> incompatibilities due to gentoo patching, etc )

If some maintainer would really want a pre-release bash tested against
an external pre-release readline, he's free to modify the ebuild to
work that way - just like how he uses to.  We can even add an internal
non-importing custom variable so this could be easily configured.  But
I don't think it's necessary to allow end-users to have that kind of
feature as well.

> "don't use external readline" would have to be the default of bash and
> everyone would have to be being encouraged to be using it that way in order
> for making the testing of that combination also a default.

Ok I don't -really- see that as a bad alternative.  The only question
is, would everyone want that?  And it still doesn't avoid the issue of
users not being able to make 'system-readline' only apply to release
versions of bash, once they enable it globally.

> Otherwise you're testing a situation that will never be a reality.

The difference in our view is whether we should allow users to test if
a -pre-release- bash would link and run well against a pre-release
readline, or not.  That really isn't something to be concerned of, if
you consider that release versions would be tested anyway.  Getting
those will-link-or-not-and-run-properly cases for pre-release versions
tested by developers should be enough.

--
konsolebox

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

[konsolebox]

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 actually don't like the idea of enabling or disabling
>>> "installed-readline" based on the `${PV} != *_rc*` condition.  If a
>>> user would want to explicitly enable "installed-readline" globally,
>>> how would he make sure that it only affects the release version of
>>> bash?  I suggest that we just don't entertain the flag (and not make
>>> it available) if the ebuild is not targetting a release version, and
>>> not use the readline installed by the system by default.  No one would
>>> need a non-release version of bash compiled against a system readline
>>> anyway.
>>
>> That's not what that does.  It doesn't enable or disable the mechanic,
>> the code I offered only changes the default for _rc.
>>
>> That is, on _rc the default is "use bundled readline implementation",
>> and on non_rc, the default is "use pre-existing readline
>> implementation".
>>
>> if the user specifies an explicit
>>
>> USE="system-readline"
>>
>> in make.conf or /etc/portage/package.use, then this "default" gets
>> overridden and the system readline implementation is always used.
>>
>> if the user speciifies an explicit
>>
>> USE="-system-readline"
>>
>> in make.conf or /etc/portage/package.use, then this "default" gets
>> overriden and the inbuilt readline is awlays used.
>>
>> Explicitly defined configuration always trumps IUSE. The "+" prefix in
>> IUSE only specifies that the USE flag defaults to on, as opposed to
>> defaulting off.
>
> I understand those elementary stuff, but my point was about whether we
> should allow the user to configure 'system-readline' on a non-release
> version of bash (i.e. make the flag available for them to configure).
> Your point is that instead of statically deciding whether we shouldn't
> use `--with-installed-readline` through `${PV} != *_rc*`, we instead
> base it on the flag, which means we allow the users to change the
> behavior of -non-release- versions of bash, which is, compiling
> against the bundled readline, to compiling against the system readline
> instead.
>
> How would a user be able to apply a distinguishing global
> configuration which would apply differently when the installing bash
> version is a release version, and when it's not?  You might say that
> `system-readline` is enabled by default in a release version anyway,
> so specifying `system-readline` explicitly is meaningless and should
> only be done if you want to change the behavior of non-release
> versions of bash.  But that's not the point.  It's about the
> consistency.  When we specify use flags in /etc/portage/make.conf, it
> shouldn't depend on the current default "enability" of a package's use
> flag.
>
> Also, do you think there could be a helpful case that one would
> install a non-release version of bash that compiles against the system
> readline?  Perhaps if you're also brave enough to install an
> pre-release version of readline to the system, there is.
>
> Again, I say that it's better that the 'installed-readline' flag or
> 'system-readline' flag is only made available in the release versions
> of bash.  And we also don't want to make it a dummy where it is just
> ignored and not excluded.

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
the user.

-- 
konsolebox

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

[konsolebox]

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 `${PV} != *_rc*` condition.  If a
>> user would want to explicitly enable "installed-readline" globally,
>> how would he make sure that it only affects the release version of
>> bash?  I suggest that we just don't entertain the flag (and not make
>> it available) if the ebuild is not targetting a release version, and
>> not use the readline installed by the system by default.  No one would
>> need a non-release version of bash compiled against a system readline
>> anyway.
>
> That's not what that does.  It doesn't enable or disable the mechanic,
> the code I offered only changes the default for _rc.
>
> That is, on _rc the default is "use bundled readline implementation",
> and on non_rc, the default is "use pre-existing readline
> implementation".
>
> if the user specifies an explicit
>
> USE="system-readline"
>
> in make.conf or /etc/portage/package.use, then this "default" gets
> overridden and the system readline implementation is always used.
>
> if the user speciifies an explicit
>
> USE="-system-readline"
>
> in make.conf or /etc/portage/package.use, then this "default" gets
> overriden and the inbuilt readline is awlays used.
>
> Explicitly defined configuration always trumps IUSE. The "+" prefix in
> IUSE only specifies that the USE flag defaults to on, as opposed to
> defaulting off.

I understand those elementary stuff, but my point was about whether we
should allow the user to configure 'system-readline' on a non-release
version of bash (i.e. make the flag available for them to configure).
Your point is that instead of statically deciding whether we shouldn't
use `--with-installed-readline` through `${PV} != *_rc*`, we instead
base it on the flag, which means we allow the users to change the
behavior of -non-release- versions of bash, which is, compiling
against the bundled readline, to compiling against the system readline
instead.

How would a user be able to apply a distinguishing global
configuration which would apply differently when the installing bash
version is a release version, and when it's not?  You might say that
`system-readline` is enabled by default in a release version anyway,
so specifying `system-readline` explicitly is meaningless and should
only be done if you want to change the behavior of non-release
versions of bash.  But that's not the point.  It's about the
consistency.  When we specify use flags in /etc/portage/make.conf, it
shouldn't depend on the current default "enability" of a package's use
flag.

Also, do you think there could be a helpful case that one would
install a non-release version of bash that compiles against the system
readline?  Perhaps if you're also brave enough to install an
pre-release version of readline to the system, there is.

Again, I say that it's better that the 'installed-readline' flag or
'system-readline' flag is only made available in the release versions
of bash.  And we also don't want to make it a dummy where it is just
ignored and not excluded.

>> I also thought using 'system-' prefix is confusing.  Does that mean
>> the system of the machine, or the system of the application?  In
>> firefox, I once thought that system-* means packages bundled within
>> it.  Perhaps I misread, or perhaps it was changed.  At that time,
>> descriptions of use flags were not widely provided yet so I could only
>> guess it based on how I built the packages.
>
> The system of the machine. As in, "Operating System". Always.
> "system-foo" usually means "foo is bundled, and toggling this flag
> toggles between using the bundled foo, or the system foo.

Yes, but I'm not talking about how it is now.  But nevermind.

>> But I don't really mind which one is used.  I also just thought
>> 'installed-readline' is better since it configures
>> `--with-installed-readline`, so one can simply have `$(use_enable
>> installed-readline)` if applicable.
>
> 'use_enable' takes a USE flag and a configure token anyway.
>
> So:
>
> $(use_enable system-readline installed-readline)
>
> is equivalent to:
>
>  use system-readline && myconf+=" --enable-installed-readline"

I know, but like I said, "simply".  `installed-readline` is just more
relative.  But I don't really care whatever gets used.

-- 
konsolebox

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

[konsolebox]

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 that it's not done automatically.
>> Instead we should add a formal use flag like 'installed-readline'.  We
>> can add it to release versions of bash ([[ ${PV} != *_rc* ]] &&
>> IUSE+=' +installed-readline'), and enable it by default.  Then we
>> change all `[[ ${PV} != *_rc* ]]` condition checks to `[[ ${PV} !=
>> *_rc* ]] && use installed-readline`.  `${PV} != *_rc*` probably should
>> also be `${PV} != *_alpha* && ${PV} != *_beta* && ${PV} != *_rc*`.
>> (See attached file for POC.)
>
> Conventionally, it would be better to have IUSE=" +system-readline"
>
> Though I'd probably opt for
>
> IUSE=" system-readline"
>
> As the default for development versions.
>
>
>if [[ ${PV} != *_rc* ]]; then
>   IUSE+=" system-readline"
>else;
>   IUSE+=" +system-readline"
>fi

I actually don't like the idea of enabling or disabling
"installed-readline" based on the `${PV} != *_rc*` condition.  If a
user would want to explicitly enable "installed-readline" globally,
how would he make sure that it only affects the release version of
bash?  I suggest that we just don't entertain the flag (and not make
it available) if the ebuild is not targetting a release version, and
not use the readline installed by the system by default.  No one would
need a non-release version of bash compiled against a system readline
anyway.

I also thought using 'system-' prefix is confusing.  Does that mean
the system of the machine, or the system of the application?  In
firefox, I once thought that system-* means packages bundled within
it.  Perhaps I misread, or perhaps it was changed.  At that time,
descriptions of use flags were not widely provided yet so I could only
guess it based on how I built the packages.

But I don't really mind which one is used.  I also just thought
'installed-readline' is better since it configures
`--with-installed-readline`, so one can simply have `$(use_enable
installed-readline)` if applicable.

-- 
konsolebox

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

[konsolebox]

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 with the installed readline,
>
> 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.
> Instead we should add a formal use flag like 'installed-readline'.  We
> can add it to release versions of bash ([[ ${PV} != *_rc* ]] &&
> IUSE+=' +installed-readline'), and enable it by default.  Then we
> change all `[[ ${PV} != *_rc* ]]` condition checks to `[[ ${PV} !=
> *_rc* ]] && use installed-readline`.  `${PV} != *_rc*` probably should
> also be `${PV} != *_alpha* && ${PV} != *_beta* && ${PV} != *_rc*`.
> (See attached file for POC.)

I missed disabling the dependency to readline when
'installed-readline' is disabled.  Here's another example.

I also fixed a repoman warning related to tinfo and renamed
'installed_readline' to 'installed-readline'.

It installs and runs well with `USE='-installed-readline tinfo' emerge
-v 'bash::local'`.

The modifications related to tinfo by the way is related to this:
https://bugs.gentoo.org/show_bug.cgi?id=588486.  I can't install bash
properly without it.

-- 
konsolebox


bash-4.4.ebuild
Description: Binary data

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

[konsolebox]

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 with the installed readline,

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.
Instead we should add a formal use flag like 'installed-readline'.  We
can add it to release versions of bash ([[ ${PV} != *_rc* ]] &&
IUSE+=' +installed-readline'), and enable it by default.  Then we
change all `[[ ${PV} != *_rc* ]]` condition checks to `[[ ${PV} !=
*_rc* ]] && use installed-readline`.  `${PV} != *_rc*` probably should
also be `${PV} != *_alpha* && ${PV} != *_beta* && ${PV} != *_rc*`.
(See attached file for POC.)

> or simply depending on USE="-readline" 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

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

[konsolebox]

I should also add that testing newer versions of bash becomes more
risky sometimes, since bash would sometimes need a newer version of
readline (see 
https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00020.html).
Rebuilding or installing a newer version of readline would cause some
other 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

[konsolebox]

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; probably something
>> close to how it's done in dev-lang/ruby.
>
> Its just eselect itself is bash. So if bash is broken . switching out 
> becomes
> impossible anyway.

Good point, but that only applies if bash can become as broken as how
you imagine it.  I had tested many development versions of bash and
none of them became that unusable, especially if it only comes to
simple scripts like eselect.  It's even more unlikely to happen with
incremental releases (beta, rc, etc.).

-- 
konsolebox

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

[konsolebox]

On Fri, Sep 30, 2016 at 5:56 AM, Andy Mender <andymenderu...@gmail.com> wrote:
> Would it be OK to have the real stable version (now, Bash 4.3) as slot :0
> and a single testing version (now, Bash 4.4) as slot:1 in addition to
> needing the "~amd64" flag?

Or simply 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

[konsolebox]

On Thu, Sep 29, 2016 at 1:54 PM, Dan Douglas <orm...@gmail.com> wrote:
> The only reason I haven't been testing this for many months
> system-wide is it's in the same slot as 4.3, and it still is. Is it
> not possible to separate them?

That would also be helpful to me since I 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)

[konsolebox]

On Mon, Jun 13, 2016 at 2:15 AM, james <gar...@verizon.net> wrote:
> and start coding your dream.

I'm not that enthusiastic.  It's up to the Gentoo masters if they
would find it helpful to the community or not.

> But the proven pathways, should be left
> intact and receive further documentation, as they are working great.
> Stop blaming others or saying that the existing pathways are discouraging,

I don't think that's exactly the case, but I gave my opinion, whether
I blame or not, or whether the existing pathways are good as they are
or not, and would stand for the next coming years.

> because they are not. Go forth and code. A large ebuild base is your best
> alley. Just stop implying that other things have to change in your favor for
> your ideas to have a chance.  What currently exists is irrelevant to proving
> your ideas.

I'm merely giving ideas and joining the discussion, which is enough
for its purpose.  Proving it is another thing.

Besides with current Gentoo community philosophy, it may not be worth
it, and is unlikely to happen.  Most people doubt innovate ideas
before actually trying to help figure out how to make it work.  I've
seen a lot of discussions like this and nothing has really happened.
I'm not really expecting anything to come out out of it.  It's not
worth the risk to waste my time and effort.  And don't tell me nothing
happened because the one who made the suggestions did nothing.  The
people in control need to do their part as well.

And people always say, "This is an open-source project.  Nothing's
stopping you from proving it.  (Go ahead, take the risk.)".  Yeah
right.

If people actually take my ideas seriously, or do anything similar to
it, then I might actually decide to help (in some ways besides coding
because I'm not in the mood to take another serious project yet, and I
also don't want to take a role with responsibility, or anything that
could leave people hanging; maybe I could be an independent beta
tester, check some issues from time to time; give 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

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

[konsolebox]

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
>> don't merge his package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> Security is out the window with what you propose

Please elaborate why it's automatically like that.

-- 
konsolebox

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

[konsolebox]

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 propose should only come upon graduating from proxy 
>> > school, imho.
>> > user-->strong-users-->proxy-->dev pathway.
>>
>> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
>> Too conservative.
>>
>> 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 package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> You're contradicting yourself. How can improving/review of pull request
> be non-mandatory, if otherwise we are to reject it? Of course, it all
> depends on how you define 'mandatory'. It's not like anybody forces you
> to do something, you know.

No, you just misinterpret. You can review pull requests.  You can
reject stuff, but don't reject them just because some laid-out steps
in the documentation has not been followed.  Some may not be
completely necessary.  I'm implying that these "academic" steps may
not be completely helpful at all times, and making us follow these
things only make making a contribution stiff and restrictive.

I'm mainly referring to the strict user-->strong-users-->proxy-->dev
pathway that James is encouraging, where it seems like you have to
become a proxy developer first (or maybe, prove yourself first; gain
first some trust), before you are acknowledged to be able to
contribute in a manner that Alexander Berntsen has been suggesting.

These stuff imply unnecessary old-fashioned restrictions that aren't
"necessarily" helpful to security.  It doesn't help encourage users to
become active.

To make it clear, I'm mostly talking about users who would want to
contribute, but doesn't necessarily take pledge on the responsibility
of maintaining a package.  And isn't that what we are mostly talking
about?  If we also talk about maintenance-ship, don't we already have
the proxy maintainer for that position?

> Sure, it may seem like we expect people to fix all the tiny issues with
> pull requests but that's just a default profile we're assuming. Many of
> the people actually *want* to do that. If you don't, you can tell us
> straight ahead and we won't waste our time asking you to.
>
> I'm also unhappy when a pull request is left open for two weeks because
> we asked user to do a simple change, and he doesn't reply. I could've
> fixed it myself faster but then the user would lose his chance to do
> it. And the worst thing, I don't even know if he wants to!

There's nothing I say against that.

>> We do already allow people to send pull requests to
>> Gentoo portage's repo in Github, but it seems like they generally only
>> allow patches that fix current packages, not new features or new
>> packages.
>
> That's not true. The rules for pull requests are pretty much the same
> as for bugs.

That's great if that's really the case, but a more transparent, less
restrictive, and more dynamic system that could attract casual
contributors would be better.   Something like a web service where
their work would be officially indexed so everyone could easily find
it, not just the current developers of the current tree snapshot
they're trying to push their work to, who may reject it, if it was
intended to be pushed.  I gave the details about this in my other
e-mail.

-- 
konsolebox

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

[konsolebox]

On Wed, Jun 8, 2016 at 9:16 PM, Alexander Berntsen <berna...@gentoo.org> wrote:
> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
>
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
>
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.
>
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.
>
>
> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.
>
> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
>
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
>
>
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.
>
> What are your thoughts?

Here's mine:

Make the layman system more open (or have a version of layman that has
more scope e.g. open-layman), but add tags to differentiate stable,
official, or trusted overlays to those which aren't: outdated,
under-provision, etc.  We have to have an open web-based registration
system where users can easily sign-up for their own overlay name which
would be mapped to a supported repository service, like Github.  The
system would time and time check for each repository for activity, and
check for updates.  It would then update the database for packages
which are provided by the overlay.  Note that it doesn't have to
always do repoman-like checks (or maybe it doesn't really have to),
but it could just do it when a user asks for a request, which could be
enqueued, and done only once in every update.

With an open system, users would be encouraged to contribute since
even if their works would not be accepted to be merged into the
official repo, it would still be available to the public for anyone to
use - where people could also easily find it.

Everything about security should already be obvious.  You can warn
users, mask user overlays by default, etc.  If we want, we can have a
comment and upvote system for every package in every overlay where
each is only dynamically created in the database if an upvote,
downvote, or comment is made.

If we are also concerned about overlay names that should only be used
officially, we should warn users that if possible, they should only
use unique names, and avoid common names, and tell them that we could
take their names for official use if we want to, granting their name
is arguably not unique.

Transfer of a package to an official repository:

If an official dev chooses to pull a package from a user overlay,
automatically it should mean that he or another dev would take place
in maintaining that package.  This would prevent the issue of
unmaintained packages, and dependencies among user overlays.

Now some people might question this since it might just drive people
to become normal contributors, and not official, but I think it's more
helpful to the system than not, since it 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

Re: [gentoo-dev] What are eblits?

[konsolebox]

On Fri, May 27, 2016 at 9:28 AM, Kent Fredric <kentfred...@gmail.com> wrote:
> That said, its a very confusing system to get your head around,
> because its *basically* yet another "mixin" system like "inherit", but
> done in bash, which itself is a rather strange language to be doing
> something as complicated as mixins.

This concept is new to me as well, but after seeing the code with `cat
/usr/portage/sys-libs/glibc/glibc-2.17.ebuild` it didn't even take me
5 or 10 minutes to understand it.  I find the implementation safe
enough if used properly.  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

[konsolebox]

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

[konsolebox]

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 at 6:55 PM, Michał Górny <mgo...@gentoo.org>
>>wrote:
>>> Dnia 19 września 2015 12:27:32 CEST, konsolebox
>><konsole...@gmail.com> napisał(a):
>>>>On Sat, Sep 19, 2015 at 4:01 PM, Michał Górny <mgo...@gentoo.org>
>>>>wrote:
>>> Which one is simpler:
>>>
>>> 1. _pre, _alpha, _beta, _rc... is earlier than no suffix, _p is newer
>>than no suffix,
>>>
>>> 2. ~ is earlier than no suffix?
>>>
>>
>>Ok I have to admit that no. 2 is simpler.  It's less descriptive and
>>requires general or specific guidelines on representing common
>>suffixes, but it allows more flexibility.  I actually had the idea
>>earlier of using _pre but using a symbol is more appropriate.  Besides
>>_pre already has a position which is > _beta and < _rc.
>>
>>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.
>
> So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate it's 
> alpha-a and not post-version a.

> Then, instead of full alpha/beta substitution we just strip the tilde.

Strip the tilde?

> So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or…

Or just like my idea of using multiple nodes which is 1.4~a1.20?
Although I don't agree about concatenating the patch (_p) or another
custom suffix's value against the preceding suffix - because the
preceding suffix could actually have a dotted value in _alpha in which
case comparing the minor numbers would be ambiguous.

>>Also what about if the package has a custom "newer than no suffix"
>>suffix used like pkg-1.4-sr5-p20?
>
> Well, sr would be used as letter version component but it shouldn't hurt.

So we add `sr` as a known suffix, what about other possible suffixes?
The point is, how would you compare custom suffixes when you don't
apply definite levels to them?  Which one would come before or after
another?  And comparing lexicographically does not always apply. Would
everyone have to convert them to presentable values where you could
calculate a number or compare in lexicographical order?

> We could even extend this to allow multiple tildes and add another symbol 
> that evaluates as higher than any version component.

Yes, like adding _post?

This really sounds like it can be solved by allowing multiple version
nodes on _pre and _post just like what I said earlier.

If you want you can have symbol versions of those but it would not be
necessary to actually remove the existing suffixes.

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

[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.
>> >
>> > So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate 
>> > it's alpha-a and not post-version a.
>>
>> > Then, instead of full alpha/beta substitution we just strip the tilde.
>>
>> Strip the tilde?
>
> SRC_URI=".../Python-${PV/~/}.tar.xz"

Ok, although a version where the appended letter on the end of it does
not always imply alpha, so it doesn't always occur on most packages.

>> > So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or…
>>
>> Or just like my idea of using multiple nodes which is 1.4~a1.20?
>> Although I don't agree about concatenating the patch (_p) or another
>> custom suffix's value against the preceding suffix - because the
>> preceding suffix could actually have a dotted value in _alpha in which
>> case comparing the minor numbers would be ambiguous.
>>
>> >>Also what about if the package has a custom "newer than no suffix"
>> >>suffix used like pkg-1.4-sr5-p20?
>> >
>> > Well, sr would be used as letter version component but it shouldn't hurt.
>>
>> So we add `sr` as a known suffix, what about other possible suffixes?
>
> No, we don't. There are *no* known magical suffixes. 'sr' is just
> text version part, like 'a', 'b', 'c', 'za'...

So you get its value for comparison by base 26, base 27 or
lexicographic order level?

>> The point is, how would you compare custom suffixes when you don't
>> apply definite levels to them?  Which one would come before or after
>> another?  And comparing lexicographically does not always apply. Would
>> everyone have to convert them to presentable values where you could
>> calculate a number or compare in lexicographical order?
>
> You can't solve every single problem. Instead, you can apply simple
> and generic rules that could work in majority of cases, and be clearly
> changed in the remaining cases.

Well that would sound like your solution doesn't solve anything at
all.  You just added another version space where you can add
translated values of custom suffixes.  Forcing people to use
translated values even makes package versions less descriptive.
That's what's worth to be called as hard-coding.

>> > We could even extend this to allow multiple tildes and add another symbol 
>> > that evaluates as higher than any version component.
>>
>> Yes, like adding _post?
>
> No, 'post' is string which again imposes limitation on upstream naming
> of versions. Use symbols as separators are symbols already.
>
>> This really sounds like it can be solved by allowing multiple version
>> nodes on _pre and _post just like what I said earlier.
>>
>> If you want you can have symbol versions of those but it would not be
>> necessary to actually remove the existing suffixes.
>
> You really can't think flexibly, can you? You always try to hardcode
> some strings, some arbitrary limitations because someone happened to
> implement Portage like this without too much thinking years ago.

I'm pretty sure I'm thinking flexible enough - as I also consider
compatibility despite also considering the use of symbols.  Maybe you
should ask yourself that instead?  Your method of doing things
generically would not apply if you can't have an algorithm that can
compare suffixes on their original form generically.  And so you also
cannot say that there is a difference between using a string or using
symbol if you can't place suffixes on them on their original form but
on their translated ones instead.

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

[konsolebox]

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 to the current solution it's full of silly special cases and 
>> > magical rules. If you really want something simple and clean, take a look 
>> > at the scheme used by pkg-config and rpm.
>>
>> Silly because it uses a not-so-monolithic approach which is more
>> convenient to implement and actually works?  What special cases or
>> magical rules where you could find it more complex than the current
>> spec?
>
> It's silly because it shifts the existing terrible structure a bit
> and doesn't really solve most of its issues

What issues?  My spec was not meant to solve issues which can't be
solved by any universal algorithm.  And it's not meant to add a
feature, but it can be used as a basis for one that would.

Perhaps provide your own spec on how you could solve those issues then
let's see if your point is correct.

> It's silly because you
> still have a fair number of limitations which make parsing harder
> rather than easier.

What limitations specifically?  I'm not sure why you'd find it harder,
as compared to the current spec.  And it's not even hard generally.

> It's silly because you still have to remember
> the relation between 'alpha', 'beta', 'rc' and 'pre'.

What kind of implementation would you have where you don't remember
those?  Do you imply to completely avoid them?  How would you get to
compare versions having alpha, beta, pre and rc then?  Do you mean to
use another library to get each one's priority?  Wouldn't that still
need to be specified in the spec?

> It's silly
> because those magical suffixes never match what upstreams use.
> And those are just a few sillinesses.

Yeah unfortunately there could be just unlimited number of possible
suffixes and unlimited ways on how they could be used so the best
thing you could do is provide what's commonly used and just let the
ebuild maintainer decide how he could work around with those suffixes
so he could present it well on the ebuild.

>> And about pkg-config and rpm: I haven't thoroughly examined them yet,
>> but you sure their implementation is applicable to Gentoo?  It might
>> just turn simpler because it's more limited or strict.  Gentoo allows
>> stages, patches and revisions and uses predefined prefixes.  Mine
>> starts on a flexible approach where "version nodes" are allowed
>> everywhere.
>
> Then you should have. It is appreciated when people do some *research*
> before throwing out random ideas on areas they have almost no idea of.

It's not a random idea as it only intends to simplify the current
spec, not drastically change it.  And it doesn't really matter for me
to thoroughly understand them if you only intend to completely change
Gentoo's packaging system to be like them.  It's not my spec's concern
to change things that way.

> 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 component ordering. Ordering (pre/post) is expressed
> explicitly, and in many more cases you can avoid writing something
> completely different than what upstream uses.

I'm not sure what you mean, but you sure that adding the ability to
expression pre/post ordering does not make the algorithm even more
complicated?  Note that you have to consider how you'd be able to
compare versions against other versions.

That also sounds to me like you just have to add a _post stage with a
+1 value and it would be enough, rather than having a complete
overhaul.

You say that you can express ordering explicitly: I find that it's
just the same problem you encounter when deciding what value to give
on _pre when encountering word versions like trial, devel, testing,
etc.

I really think adding more commonly used suffixes should be enough.

Btw, can you give a link on how the pre/post ordering is expressed?  I
can't find any RPM versioning spec that describes how it's done.

>> If perhaps you mean to completely overhaul Gentoo's way of
>> implementing package versions, I don't think that would work.
>
> And is your change going to work? Because if you understood how ebuilds
> work, you'd know you practically can't change versioning because you'd
> immediately break compatibility between 'old' and 'new' ebuilds.

Except that mine is unlikely to break compatibility with current
packages.  You have issues against the very foundations of the current
implementation, but that's not really about my spec per se.  You seem
to be barking at the wrong tree and I don't think that would help.

> This
> isn't 

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

[konsolebox]

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 like hardcoded suffix
>> lists or forced component ordering. Ordering (pre/post) is expressed
>> explicitly, and in many more cases you can avoid writing something
>> completely different than what upstream uses.
>
> I'm not sure what you mean, but you sure that adding the ability to
> expression pre/post ordering does not make the algorithm even more
> complicated?  Note that you have to consider how you'd be able to
> compare versions against other versions.
>
> That also sounds to me like you just have to add a _post stage with a
> +1 value and it would be enough, rather than having a complete
> overhaul.
>
> You say that you can express ordering explicitly: I find that it's
> just the same problem you encounter when deciding what value to give
> on _pre when encountering word versions like trial, devel, testing,
> etc.
>
> I really think adding more commonly used suffixes should be enough.
>
> Btw, can you give a link on how the pre/post ordering is expressed?  I
> can't find any RPM versioning spec that describes how it's done.

This just came to me.  I think I may have got your idea, and I thank
you for your input.  We can actually allow multiple nodes on _pre and
_post (and possibly other suffixes) so we can map custom suffixes as
numbers.  For example:  "pkg-1.4.2_preX.Y.Z"  That way we could allow
maintainers to have their own custom levels for the suffixes.  It
would also not break compatibility with previous spec.  And this would
be conceptually more useful if we add _post as another stage with
value of 1.

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

[konsolebox]

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 the implementation.

Comments are welcome.

1 Version Specification

A version is composed of four component sets: the base part, the
stage, the patch and the revision.

Each component is composed mainly of version nodes to represent their
level values.

When a component is not specified, it gets a default node value of {0}.

1.1 Version Nodes

Nodes start basically with a number and then is optionally followed by
a set of letters.

Numbers and letters can coexist alternatingly to represent a single
node.  The number of consecutive letters is also not limited to 1.
For example: "1a4xy" is allowed (can be restricted).

Each set of digits represents a single decimal number.  Leading zeros
hold no meaning.

The numerical equivalent of a set of letters is calculated in base of
27 (0 exists along with it but is not included as a symbol).

Version nodes after processing are basically just an array of signed
integers where each set of digits or letters are converted to their
numerical value.

1.2 Version Parts

1.2.1 The Base Part

The base version is simply a set of version nodes that are separated
by dots.  Examples: "4.1.2", "4.1.2aa" "4a", "4a.1", "4a.1.2".

After processing, the base version is an array of version nodes.

It is required.

1.2.2 The Stage Part

The stage part starts with _alpha, _beta, _pre or _rc.  Their
numerical values are -4, -3, -2 or -1 respectively.  Each of them can
optionally be followed by a version node string.  For example:
"_alpha01".

The resulting value for the stage after processing is a single version
node where the first value in it is the numerical values of _alpha,
_beta, _pre or _rc, and the other values are based on the added node
string.

A version without a stage has a default stage value of {0}.

The stage part is optional and can be specified only once after the
base part.  It can't be specified as a modifier for the patch, for the
revision, or for another stage.

1.2.3 The Patch Part

The patch part begins with _p and is followed by a version node
string.  For example: "_p20150105a".

The patch part is optional and can be specified after the base part or
after the stage part, but not after the revision.  It can only be
specified once.

It is processed as a single version node based on its version node string.

A version without a patch has a default patch value of {0}.

1.2.4 The Revision

The revision starts with -r and is followed by a number.

It is processed as a single version node based on its version node string.

A version without a revision has a default revision value of {0}.

1.3 Comparing Versions

Versions are compared as version nodes and the algorithm is simple:
each component and subcomponent is compared from left to right.

Anything that gives a difference decides which version is greater or lesser.

Any non-existing version-node has a default value of {0}.

Any non-existing element of a version node has a default value of 0.

If no difference is found during the process, it would mean that both
versions are equal.

1.3.1 Concept Code

  #!/usr/bin/ruby

  class ::Array
def adaptive_transpose
  h_size = self.max_by{ |a| a.size }.size
  v_size = self.size

  result = Array.new(h_size)
  with_index = self.each_with_index.to_a.freeze

  0.upto(h_size - 1) do |i|
result[i] = Array.new(v_size)
with_index.each{ |a, j| result[i][j] = a[i] }
  end

  result
end
  end

  module Portage
class PackageVersion
  class Node < ::Array
def initialize(*values)
  self.concat(values)
end

def compare_with(another)
  [self, another].adaptive_transpose.each do |a, b|
a ||= 0
b ||= 0
return -1 if a < b
return 1 if a > b
  end

  return 0
end

def self.parse(*args)
  result = new

  args.each do |a|
case a
when Integer
  result << a
when /^[[:digit:]][[:alnum:]]*$/
  a.scan(/[[:digit:]]+|[[:alpha:]]+/).each_with_index.map do |b, i|
if i.even?
  str = b.gsub(/^0+/, '')
  result << (str.empty? ? 0 : Integer(str))
else
  value = 0

  b.downcase.bytes.reverse.each_with_index do |c, i|
value += 27 ** i * (c - 96)  ## a == 1, z == 26,
and 0 exists but is not used
  end

  result << value
end
  end
else
  raise ArgumentError.new("Invalid node string: #{a.inspect}")
end
  end

   

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

[konsolebox]

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

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

[konsolebox]

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 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
>>
>
> Nah, I'm talking about epochs.  When a package wishes to reversion
> itself, changing how it does versioning.
>
> For instance, nova is going to go from 2015.1.1 to 12.0.0, so 2015.n.x
> is epoch 1, and 12.y.z is epoch 2.  Think of it like super versioning.
>
No.. I believe it's up to the ebuild maintainer what versioning
strategy he'd use.  Personally I don't mind having 12.x.y and 2015.x.y
to co-exist.  You just have to mask 2015.x.y with keywords if
necessary.  Some packages actually mix version numbers.  It just
depends.

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

[konsolebox]

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 far from common it is (as proven by the example
>> code).  The workaround for such rare cases should be done on the
>> ebuild's version.
>>
>
> Just have a look on CPAN module versions. You'll see that it's much more 
> common than you think. Just few examples:
> http://search.cpan.org/~pip/Math-BaseCnv-1.6.A6FGHKE/
> http://cpansearch.perl.org/src/MMCLERIC/Ubic-1.58_01-TRIAL/
>
> And so on. There are much more than that. Also strange version translations, 
> where new release may just start to use new version scheme. And so on, and so 
> on.

And the ambiguous part of the current spec which interprets numbers
starting with 0 differently didn't really help much in solving
problems in adapting those irregular versioning schemes.

That is why it's better to just implement a more simple and consistent
universal approach and keep the decisions on how those irregular
versions should be represented in ebuilds to the ebuild maintainers.

As for A6FGHKE and TRIAL, it's impossible to tell their actual level
values so even if we choose to map them lexicographically, we would
still not be able to use a universal algorithm that could tell how it
affects the base version (just like how stages affects it) and how it
compares with other values as well.  So it would still be up to the
maintainer how he would represent the versions on ebuilds.

One could do:

Math-BaseCnv-1.6.20YYMMDD

and

Ubic-1.58.01.20YYMMDD or Ubic-1.58.01_pre20YYMMDD

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

[konsolebox]

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.
>
> Versioning isn't ideal and simple.

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).  The workaround for such rare cases should be done on the
ebuild's version.

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

[konsolebox]

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 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
> format?  I.e. one that shifts from 2 digit to 3 digit format where it
> intends to have the third digit as a subversion?

And I find it so wrong that it makes me think that it shouldn't have
been acknowledged by any packaging system.  That versioning madness
should have been just fixed in the ebuilds level.

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

[konsolebox]

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
format?  I.e. one that shifts from 2 digit to 3 digit format where it
intends to have the third digit as a subversion?

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

[konsolebox]

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, but they've partially changed in some places but not others.
>
> The rules are a mess because they need to a reasonable job of dealing
> with all the crazy.

But these rules may no longer be applicable with the current packages.
Besides I think we can just enforce using 3 digits on versioning
ebuilds when we see a package that uses both 2 digits and 3 digits.

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

[konsolebox]

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.

[konsolebox]

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
something else) but anyway, if we don't use another operator, would *
no longer match strings like a glob matcher?  For example,
`=cat/foo-5.2015*` would no longer match cat/foo-5.20150102.  On the
other hand if we still allow to match like glob but have a workaround
by allowing expressions like `=cat/foo-5.10.*`, we would now have to
use 4 lines in order to accurately specify the targets:
`=cat/foo-5.10`, `=cat/foo-5.10.*`, `=cat/foo-5.10-*` and
`=cat/foo-5.10_*`.  So should we no allow [.-_]* so we can reduce them
to two?

(Come to think of it, the @ operator is already used by sets so we
can't have @cat/foo-5.10.  But we can have =cat/foo-5.10@.  Or
=cat/foo-5.10~.  But the latter could be found ambiguous or
misinforming since ~cat/pkg-5.10 is already thought to only target
revisions.)

> Is there any real need to express this in a single line except for
> saving a single line?

There are areas where only a single expression is applicable like on a
CLI query, or on package.* rules where applying or disabling a flag or
keyword on specific version and unapplying or enabling the same flag
or keyword on excluded versions may not always be sensible.  Having to
use more than a single expression adds noise and complexity.

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

[konsolebox]

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:
>>>> 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.

Here are my issues if we try to modify =* and not add another operator:

1) We'll completely abandon having an operator that matches the
remaining parts of a version number for good: =cat/foo-5.2015* would
no longer work.

2) We'll have to decide if we should remove the leading zeros of a
version number: should 5.01.0 and and 5.1.2 be the matched the same if
I used =5.01*?  We can only either allow it or not.  We keep one
feature, we lose the other feature.  If we use another operator,
=5.01* could just stay strict on matching 5.01*, whereas the operator
could have the function of treating them like decimals instead.  We
can keep =* have the string matching feature while have another
operator do the more-on-arithmetic one.

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

[konsolebox]

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 an expression like '~>pkg-1.0.2a' and it would be equivalent
>> to '>=pkg-1.0.2a' and '<pkg-1.0.2b'.  Another expression like
>> '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and
>> '<pkg-1.0.3'.
>
> It strikes me that this likely is better solved using subslots, if it
> is ABI compatability you're wishing to retain?

Subslots are only applicable when creating ebuilds.  And if I'm
creating an ebuild, should I wait for the dependency to have a
subslot?  Also like I said earlier I find that slots are more for
grouping but are not really specific to a parent version.  It's also
not always about ABI compatibility.

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

[konsolebox]

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
versioning (http://semver.org/).

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

[konsolebox]

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,
> 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.

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

[konsolebox]

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.

[konsolebox]

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 be slotted with e.g. pkg-1.0.2g:1.0.2.
> Anything depending on it would use `pkg:1.0.2`, and the pkg-1.0.3a
> ebuild could use SLOT="1.0.3" and be called as a dependency via
> `pkg:1.0.3`.
Slotting means isolation (most of the time as a group and not necessarily on a
parent version), but that's not always the case when you're just
wanting to target
a specific version.  With the operator we could avoid unnecessary
overkill using slots.

Also that would only apply when you're creating an ebuild.

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

[konsolebox]

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
>
> When it only matches 1.0.2 and 1.0.2.*
>
> You're reading it in shell glob notation and not the portage notation,
> that the trailing dot is *implied*, which is why explictly stating it
> is illegal.

Test shows that it doesn't work that way.  Here I created a dummy bash-4.30:

# emerge -pvO =app-shells/bash-4.3_p42

These are the packages that would be merged, in order:

[ebuild U ~] app-shells/bash-4.3_p42::gentoo [4.3_p39::gentoo]
USE="net nls (readline) -afs -bashlogger -examples -mem-scramble
-plugins -vanilla" 6 KiB

Total: 1 package (1 upgrade), Size of downloads: 6 KiB

# emerge -pvO '=app-shells/bash-4.3*'

These are the packages that would be merged, in order:

[ebuild U ~] app-shells/bash-4.30::local [4.3_p39::gentoo]
USE="net nls (readline) -afs -bashlogger -examples -mem-scramble
-plugins -vanilla" 0 KiB

Total: 1 package (1 upgrade), Size of downloads: 0 KiB

# ls /var/db/pkg/sys-apps/portage-2.2.20.1/

> https://devmanual.gentoo.org/general-concepts/dependencies/index.html#ranged-dependencies
>
>> To specify "version 2.x (not 1.x or 3.x)" of a package, it is necessary to 
>> use the asterisk postfix.
>> Note that the equals sign is mandatory, and that there is no dot before the 
>> asterisk.

The provided example was `DEPEND="gtk? ( =x11-libs/gtk+-1.2* )"`.  I'm
not sure if that was accurately implying "version 1.2.x (not 1.1.x or
1.3.x)".

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

[konsolebox]

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 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] Re: Request to add ~> atom prefix operator on Portage.

[konsolebox]

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 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.

[konsolebox]

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.

[konsolebox]

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 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.