[gentoo-dev] Proposal to fix distutils_install_for_testing to install proper egg-info

[Mathy Vanvoorden]

Hi,

As requested in this PR I submit this patch to gentoo-dev for review /
approval.

https://github.com/gentoo/gentoo/pull/2746

The commit message:

Currently distutils_install_for_testing does not install the complete
egg-info into ${TEST_DIR}. This was first noticed by W. Trevor King and
reported in bug #524322. Based on info found in the related upstream
setuptools bug I added the necessary call to setuptools to create the
complete egg_info.

Without this certain packages (like cryptography) fail during testing
because they use introspection but the metadata isn't available.

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=524322

--
Met vriendelijke groeten,
Best regards,

Mathy Vanvoorden
From 5a073983287a8fa097c5fbc60826e49aef45004b Mon Sep 17 00:00:00 2001
From: Mathy Vanvoorden 
Date: Sat, 5 Nov 2016 00:01:51 +0100
Subject: [PATCH] distutils-r1 : make distutils_install_for_testing install
 proper egg-info

Currently distutils_install_for_testing does not install the complete
egg-info into ${TEST_DIR}. This was first noticed by W. Trevor King and
reported in bug #524322. Based on info found in the related upstream
setuptools bug I added the necessary call to setuptools to create the
complete egg_info.

Without this certain packages (like cryptography) fail during testing
because they use introspection but the metadata isn't available.

Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=524322
---
 eclass/distutils-r1.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index fb0362c..2db3be8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -288,6 +288,8 @@ distutils_install_for_testing() {
PYTHONPATH=${libdir}:${PYTHONPATH}
 
local add_args=(
+   egg_info
+   --egg-base="${libdir}"
install
--home="${TEST_DIR}"
--install-lib="${libdir}"
-- 
2.7.3

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

[konsolebox]

On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny  wrote:
> On Wed, 9 Nov 2016 14:32:33 +0800
> konsolebox  wrote:
>
>> On Tue, Nov 8, 2016 at 6:39 PM, Michał Górny  wrote:
>> >>dev-foo/bar{:1.3 :1.4 :1.5}  ## Solves "A. Range dependencies vs
>> >>slotting"
>> >
>> > 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 everywhere in every context of every different type
of conditional element being checked makes things more complex.

>> > 4. Do we allow different ranges per slots?
>>
>> Seems possible like {:>=1.3 :<=1.5}.  Comparing subslots is also just
>> about grouping where in x/y, x is the major and y is the minor.  Major
>> versions are compared first, and minor versions are only compared if
>> major versions are equal.
>
> Slots are not numbers nor versions. You can't compare them.

Not that I really ca

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

[Michał Górny]

On Wed, 9 Nov 2016 18:17:25 +0800
konsolebox  wrote:

> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny  wrote:
> > On Wed, 9 Nov 2016 14:32:33 +0800
> > konsolebox  wrote:
> >> 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?

I'm sorry, I misread that.

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

I meant newest installed.

> >> 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 everywhere in every context of every different type
> of conditional element being checked makes things more complex.

I think you're forgetting the most important point here. Dependency
specifications are not only used to check some installed package for
match. They also need to make it possible to semi-reasonably pull
in additional packages that could be used to satisfy the dependency.

The more complex conditions you allow, the harder the task becomes for
the PM and the slower Portage becomes (because it needs to consider
more variants of a possible solution).

> >> > 4. Do we allow different ranges per slots?  
> >>
> >> Seems possible like {:>=1.3 :<=1.5}.  Comparing subslots is also just
> >> about grouping where in x/y, x is the major and y is the minor.  Major
> >> versions are compared first, and minor versions are only compared if
> >> major versions are equal.  
> >
> > Slots are not numbers nor versions. You can't compare them.  
> 
> Not that I really care about ranges for slots, but can you explain
> why?  Is that somehow dependent to a current implementation?

Slots are free-form strings by design. This has its uses, including
named slots ('stable', 'testing'...), subslots representing SONAMEs of
multiple libraries ('liba0-libb4')...

> >> > How do we combine various order of data?  
> >>
> >> I need specific example/detail on that, or perhaps I already have that
> >> answered above.  
> >
> > dev-foo/bar(:1.6 {>=3.4 :5[foo]} ([bar] <3.7))  
> 
> I'm yet to add opinion on allowing use flags to be used anywhere
> besides outside a group and only once.  But that looks doable,
> although seems more complicated to implement, or at least heavier,
> maybe.  You should also correct that a bit:
> 
> dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))

Why are you forcing whitespace in some contexts and not in other
contexts? Does this mean the common case would look like:

  dev-foo/bar >= 1.4 :1.6 [bar]

?

> > Yes, I am. In some cases, regexp is the only thing you have
> > (e.g. in XSD). The major problem with current syntax is that you can't
> > properly validate restrict="" in XSD because you'd have to
> > backreference operator.  
> 
> I don't know XSD, but it's good if we can improve it as well so we can 
> innovate.

Err, are you talking Gentoo is supposed to request full FSM to be
included in XML Schema? I honestly doubt standar

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

[konsolebox]

On Wed, Nov 9, 2016 at 7:12 PM, Michał Górny  wrote:
>> On Wed, Nov 9, 2016 at 3:36 PM, Michał Górny  wrote:
>> >> 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."
>
> I meant newest installed.

Ok, so do you think := can be used anywhere just like any other
conditional element?

>> >> 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 everywhere in every context of every different type
>> of conditional element being checked makes things more complex.
>
> I think you're forgetting the most important point here. Dependency
> specifications are not only used to check some installed package for
> match. They also need to make it possible to semi-reasonably pull
> in additional packages that could be used to satisfy the dependency.
>
> The more complex conditions you allow, the harder the task becomes for
> the PM and the slower Portage becomes (because it needs to consider
> more variants of a possible solution).

I still need to confirm things in a more technical manner, so I can't
make a reply about that for now.

> Slots are free-form strings by design. This has its uses, including
> named slots ('stable', 'testing'...), subslots representing SONAMEs of
> multiple libraries ('liba0-libb4')...

I see.

>> >> > How do we combine various order of data?
>> >>
>> >> I need specific example/detail on that, or perhaps I already have that
>> >> answered above.
>> >
>> > dev-foo/bar(:1.6 {>=3.4 :5[foo]} ([bar] <3.7))
>>
>> I'm yet to add opinion on allowing use flags to be used anywhere
>> besides outside a group and only once.  But that looks doable,
>> although seems more complicated to implement, or at least heavier,
>> maybe.  You should also correct that a bit:
>>
>> dev-foo/bar(:1.6 {>=3.4 (:5 [foo])} ([bar] <3.7))
>
> Why are you forcing whitespace in some contexts and not in other
> contexts? Does this mean the common case would look like:
>
>   dev-foo/bar >= 1.4 :1.6 [bar]
>
> ?

Sorry, I misguessed.  I thought you wanted :5 and [foo] to be used
together; that both items should be true.

>> > Yes, I am. In some cases, regexp is the only thing you have
>> > (e.g. in XSD). The major problem with current syntax is that you can't
>> > properly validate restrict="" in XSD because you'd have to
>> > backreference operator.
>>
>> I don't know XSD, but it's good if we can improve it as well so we can 
>> innovate.
>
> Err, are you talking Gentoo is supposed to request full FSM to be
> included in XML Schema? I honestly doubt standard bodies will seriously
> consider that.

I see. I can't comment much on that unfortunately.

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

Re: [gentoo-dev] tmpfiles: call for testers

[Mike Gilbert]

On Wed, Nov 9, 2016 at 2:11 AM, Zac Medico  wrote:
> On 11/08/2016 10:44 PM, Daniel Campbell wrote:
>> On 11/08/2016 05:02 PM, Rich Freeman wrote:
>>> On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean  wrote:
 On Tue, 8 Nov 2016 17:41:02 -0600
 William Hubbs  wrote:
>
> The plan, once the first release is out, is to rewrite this utility
> in a better language. I'm considering C, but if I am comfortable by
> that time in Go or Rust, I may use one of them.
>

 For a low-level utility that is likely going to be in the default
 @system set, please use C. Adding dependencies on the go or rust
 compilers for this is not very nice.

>>>
>>> Assuming I'm looking at the right sources, the actual systemd
>>> implementation is only 2342 lines of C.  Glancing at the includes, I'm
>>> not convinced it even requires systemd to run.
>>>
>>> You might want to take a look at either just creating a split ebuild,
>>> or tweaking it to work standalone if necessary.
>>>
>> Is that including any headers and/or libraries shared by the systemd
>> umbrella?
>>
>
> It has a huge list of includes for internal libraries, from acl-util.h
> to util.h:
>
> https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c

Also, it is linked against libsystemd-shared.so, which is a 2.1 M blob
on my system. For comparison, libc-2.23.so is 1.7 M.

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

[Michael Orlitzky]

On 11/09/2016 02:42 AM, Michał Górny wrote:
> 
>>   apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ),
> 
> In what order is that interpreted? Remember that you aren't allowed to
> reference USE flags not in IUSE without (+) and (-). So if things are
> parsed left-to-right, you may end up applying an invalid USE
> restriction before the version restriction.
> 

Equivalent to >=www-servers/apache-2.4[apache2_modules_cgi]. The wording
of the PMS might need to be changed, but it makes no difference if you
think of the USE constraint as being applied before or after the version
constraint. In other words, we could make the rule: you can't reference
versions that don't meet a USE constraint without (+) or (-).

Re: [gentoo-dev] tmpfiles: call for testers

[Rich Freeman]

On Wed, Nov 9, 2016 at 8:30 AM, Mike Gilbert  wrote:
> On Wed, Nov 9, 2016 at 2:11 AM, Zac Medico  wrote:
>> On 11/08/2016 10:44 PM, Daniel Campbell wrote:
>>> On 11/08/2016 05:02 PM, Rich Freeman wrote:
 On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean  wrote:
> On Tue, 8 Nov 2016 17:41:02 -0600
> William Hubbs  wrote:
>>
>> The plan, once the first release is out, is to rewrite this utility
>> in a better language. I'm considering C, but if I am comfortable by
>> that time in Go or Rust, I may use one of them.
>>
>
> For a low-level utility that is likely going to be in the default
> @system set, please use C. Adding dependencies on the go or rust
> compilers for this is not very nice.
>

 Assuming I'm looking at the right sources, the actual systemd
 implementation is only 2342 lines of C.  Glancing at the includes, I'm
 not convinced it even requires systemd to run.

 You might want to take a look at either just creating a split ebuild,
 or tweaking it to work standalone if necessary.

>>> Is that including any headers and/or libraries shared by the systemd
>>> umbrella?
>>>
>>
>> It has a huge list of includes for internal libraries, from acl-util.h
>> to util.h:
>>
>> https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c
>
> Also, it is linked against libsystemd-shared.so, which is a 2.1 M blob
> on my system. For comparison, libc-2.23.so is 1.7 M.
>

My understanding is that this is a once-and-done executable, not a
daemon.  I won't debate that it probably could be refactored or redone
in a smaller overall package.  However, the only real cost to it being
large is disk space use, a miniscule amount of additional load time
(we are talking about an rc solution coded in bash, which has tons of
load time penalties), and a few MB or RAM during the short time that
it is running.

Don't get me wrong.  I don't have a problem if somebody wants to take
the time to basically rewrite it.  But, you're probably going to spend
a lot of time chasing edge cases with compatibility with an upstream
moving target.  I'm sure a lot of the tmpfiles.d features are rarely
used, but do you really want to end up hosting debates over whether
you really need btrfs subvolume support, POSIX ACL support, xattr
support, age-checking and cleanup, support for machine IDs, and so on?

In any case, my goal was to toss the option out there, either as a
short-term or long-term solution.  You have a working implementation
that probably could get the job done with minimal effort to adapt it,
and it is the same implementation virtually every other distro is
using and which is well-maintained upstream.  Now, I haven't tried to
run it under openrc and there could be some fatal flaw in the
suggestion. But, I probably wouldn't be deterred by a couple of
libraries.

-- 
Rich

Re: [gentoo-dev] tmpfiles: call for testers

[Michał Górny]

On Tue, 8 Nov 2016 17:41:02 -0600
William Hubbs  wrote:

> All,
> 
> as part of bug 599044 [1], I have  created a tmpfiles project which is a
> standalone utility to handle systemd style tmpfiles.d files.
> 
> There is currently a live ebuild in the tree, but I haven't done any
> releases yet.
> 
> Take a look at it, and anything about it is open for discussion at this
> point.
> 
> The name is a bit vague, but honestly I couldn't figure out a better
> name. I don't really want openrc in the name, because this is meant to
> be more generic than  that; it is not meant to require OpenRC to run.
> OpenRC will use it, but not the other way around.

opentmpfiles? tmprc? :-D

> If you see any bugs, now is also the time to let me know before any
> releases are out.
> 
> The plan, once the first release is out, is to rewrite this utility in a
> better language. I'm considering C, but if I am comfortable by that time
> in Go or Rust, I may use one of them.

Sounds like a good way to lose 95% [1] of users.

[1]: Note: it's just a random approximation. It may be underestimated.

-- 
Best regards,
Michał Górny



pgpeLT4Wywc5T.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles: call for testers

[William Hubbs]

On Wed, Nov 09, 2016 at 03:33:10PM +0100, Michał Górny wrote:
> On Tue, 8 Nov 2016 17:41:02 -0600
> William Hubbs  wrote:
> 
> > All,
> > 
> > as part of bug 599044 [1], I have  created a tmpfiles project which is a
> > standalone utility to handle systemd style tmpfiles.d files.
> > 
> > There is currently a live ebuild in the tree, but I haven't done any
> > releases yet.
> > 
> > Take a look at it, and anything about it is open for discussion at this
> > point.
> > 
> > The name is a bit vague, but honestly I couldn't figure out a better
> > name. I don't really want openrc in the name, because this is meant to
> > be more generic than  that; it is not meant to require OpenRC to run.
> > OpenRC will use it, but not the other way around.
> 
> opentmpfiles? tmprc? :-D

Hmm, I don't know if you are being serious or just messing with me, but
if you are being serious I'll consider opentmpfiles. In a way that makes
sense because of openrc/openresolv/opentmpfiles.

If there are no objections I'll rename it.


William



signature.asc
Description: Digital signature

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

[Daniel Campbell]

On 11/06/2016 02:52 AM, Michał Górny wrote:
> Hi, everyone.
> 
> Following my previous RFC wrt version operator problems, I'd like to
> start the second part of the discussion: how to improve 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
> 
I think it complicates version matching. Of course, matching the correct
version is a difficult task in itself. Anything that requires the least
necessary change and improves readability and utility the most should
get in. I like the idea of version ranges and slot ranges, but it's
tough to figure out which form is best for that.

Then we have the pesky * that, when used in a version spec, doesn't
follow intuition. Unless a package is slotted for each major or
major.minor version, there isn't a way currently (that I know of) to
express "pull in any version 1.2.x of app-misc/foobar" in a single
declaration/line.

In an attempt at a solution: we already use [] for USE, and () are for
groupings. If bash doesn't yell at us much, maybe {} would be good for
version restrictions. Maybe something like:

>=app-misc/foobar-{1.2..1.4}:=[baz]

To mean "any version of 1.2 or greater, up to version 1.4, inclusive".
We could add in asterisk support to match any sub versions, e.g.
{1.2*..1.4}, but it could get really messy.

While the initial proposal to put the operator in a better place seems
nice on paper, I can only think of the massive amount of work that'd
need to be done to get that change pushed through and re-educate fellow
devs on how to do things going forward. Maybe we should go through some
particularly tricky ebuilds and "try out" the new ideas, to see what the
final product looks like.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles: call for testers

[Michał Górny]

On Wed, 9 Nov 2016 18:15:42 -0600
William Hubbs  wrote:

> On Wed, Nov 09, 2016 at 03:33:10PM +0100, Michał Górny wrote:
> > On Tue, 8 Nov 2016 17:41:02 -0600
> > William Hubbs  wrote:
> >   
> > > All,
> > > 
> > > as part of bug 599044 [1], I have  created a tmpfiles project which is a
> > > standalone utility to handle systemd style tmpfiles.d files.
> > > 
> > > There is currently a live ebuild in the tree, but I haven't done any
> > > releases yet.
> > > 
> > > Take a look at it, and anything about it is open for discussion at this
> > > point.
> > > 
> > > The name is a bit vague, but honestly I couldn't figure out a better
> > > name. I don't really want openrc in the name, because this is meant to
> > > be more generic than  that; it is not meant to require OpenRC to run.
> > > OpenRC will use it, but not the other way around.  
> > 
> > opentmpfiles? tmprc? :-D  
> 
> Hmm, I don't know if you are being serious or just messing with me, but
> if you are being serious I'll consider opentmpfiles. In a way that makes
> sense because of openrc/openresolv/opentmpfiles.
> 
> If there are no objections I'll rename it.

Just throwing names alike openrc/netifrc around. I don't mind either
way.

-- 
Best regards,
Michał Górny



pgpgJnLztxQ3G.pgp
Description: OpenPGP digital signature