[gentoo-dev] Revisiting version-related tree policies

[gentoo-dev] Revisiting version-related tree policies

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 8491 bytes --]

Hi, everyone.

As part of our work on version operators, we've noticed some issues
with our version policies. ulm has done some additional research on
the topic and now I'd like to open a discussion on our rules.


== PMS rules ==
PMS specifies only minimal syntax for versions, that is allowed types
and order of components. It does not define any range, length or
count limits. In other words, your versions can be infinitely long,
with infinitely many components and thanks to 'negative' suffixes such
as _alpha.._rc, also with infinite precision. Revisions can grow up to
infinity as well.

Fun fact: for every existing versions (without considering revisions!)
A and B, you can always create a new version X, so that A < X < B. For
example, if A = 1.4, B = 1.4_p1, X can be 1.4_p1_pre. For A = 1.4,
B = 1.4_p1_pre, X = 1.4_p1_pre_pre and so on.


== Current Gentoo policy ==
ulm has found a tiny note in the devmanual [1] stating:

| No integer part of the version may be longer than 18 digits.

The rationale is supposedly to be able to practically hold each
component in 64-bit integer type.

[1]:https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules


== Practical implications ==
Aside to purely technical matters, I think the free-form versioning has
two major drawbacks:

1. Some of the more creative versions are confusing to everyone (e.g.
when you are trying to figure out what particular components mean)
and really hard to type correctly,

2. Getting safe lower or upper bound for <, <=, >=, > deps is sometimes
hard to impossible. For example, >=foo-1.4_alpha wouldn't catch
1.4_alpha_rc which is valid. And <=foo-1.4-r9999 wouldn't catch
foo-1.4.r-10000.


== Currently used versions in ::gentoo ==
[Note: after noting this all down I've noticed my results don't include
masked packages]

=== Version lengths (not counting revisions) ===
The longest version used is 23 characters long. The longest are:

23 app-emacs/limit 1.14.10_pre200811252332
23 app-i18n/man-pages-ru 3.71.2209.1992.20140911
23 app-i18n/man-pages-ru 3.81.2230.2080.20160117
23 net-ftp/pybootd 1.5.0_pre20110524131526
22 sys-auth/google-authenticator 1.01_pre20160307231538

Key|Ct    (Pct)    Histogram
 5|14597 (39.72%) ******************************************************
 6| 6496 (17.68%) ************************
 3| 3954 (10.76%) ***************
 7| 3396  (9.24%) *************
 4| 2914  (7.93%) ***********
10| 2288  (6.23%) *********
 8| 1155  (3.14%) *****
 9|  478  (1.30%) **
 2|  271  (0.74%) *
 1|  239  (0.65%) *

I don't see any problem here.


=== Revision values ===
The highest revisions are:

2014120900 www-servers/xsp 2014.12
9999 app-crypt/keylookup 2.2
500 kde-misc/openofficeorg-thumbnail 1.0.0
301 dev-libs/libappindicator 12.10.0
301 dev-libs/libindicator 12.10.1

Key|Ct    (Pct)    Histogram
  0|26311 (71.60%) *****************************************************
  1| 6133 (16.69%) *************
  2| 1792  (4.88%) ****
  3|  841  (2.29%) **
  4|  526  (1.43%) **
  5|  380  (1.03%) *
  6|  319  (0.87%) *
 10|  275  (0.75%) *
  7|   40  (0.11%) *
  8|   26  (0.07%) *
  9|   23  (0.06%) *
100|   19  (0.05%) *
 11|   10  (0.03%) *
200|    7  (0.02%) *
300|    6  (0.02%) *

As expected, the most common are revisions increasing monotonically.
However, multiples of 100 are also popular.

The revision number of 9999 is suspicious, and 2014120900 is clearly
pathological -- and probably should be replaced by _pre or _p.

It should be noted that e.g. ::progress overlay is known to use
revisions 10000+ to override Gentoo ebuilds.


=== Numeric version component lengths ===
The longest numeric version component is 14 characters long.
The longest are:

14 20141110122616 dev-vcs/pwclient 20141110122616
14 20140414130214 dev-ruby/arel 5.0.1.20140414130214
14 20121105131501 dev-vcs/pwclient 20121105131501
12 201607172312 sys-apps/gradm 3.1.201607172312
12 201607021514 app-crypt/gentoo-keys 201607021514
12 201606062304 mail-filter/opensmtpd-extras 5.9.2.201606062304
12 201603152148 sys-apps/gradm 3.1.201603152148
12 201507191652 sys-apps/gradm 3.1.201507191652
12 201506180105 app-misc/xmind 3.5.3.201506180105
12 201505061057 net-libs/libasr 1.0.1.201505061057
12 201411201906 app-misc/xmind 3.5.1.201411201906
12 201401221918 app-misc/xmind 3.4.1.201401221918
10 2016020301 dev-perl/Regexp-Common 2016020301.0.0
10 2013031301 dev-perl/Regexp-Common 2013031301.0.0
10 2009041301 dev-perl/Geography-Countries 2009041301.0.0

Key|Ct    (Pct)    Histogram
 1|81628 (82.51%) ******************************************************
 2|11700 (11.83%) ********
 8| 2772  (2.80%) **
 3| 2063  (2.09%) **
 4|  665  (0.67%) *
 5|   38  (0.04%) *
 6|   28  (0.03%) *
 7|   20  (0.02%) *
12|    9  (0.01%) *
14|    3  (0.00%) *
10|    3  (0.00%) *

All longer values seem to be reserved for timestamps with various
precisions.


=== Version suffix lengths ===
The longest version suffix is 17 characters long (14 digits). The
longest are:

17 pre20161004153257 net-irc/kvirc 5.0_pre20161004153257
17 pre20160801092805 net-irc/kvirc 5.0_pre20160801092805
17 pre20160307231538 sys-auth/google-authenticator 1.01_pre20160307231538
17 pre20110524131526 net-ftp/pybootd 1.5.0_pre20110524131526
15 pre200811252332 app-emacs/limit 1.14.10_pre200811252332
15 p20160215155418 sys-apps/net-tools 1.60_p20160215155418
...
13 p200709030413 app-emacs/mu-cite 8.1_p200709030413
13 alpha20110303 dev-python/pivy 0.5_alpha20110303
12 beta20150411 app-vim/rust-vim 1_beta20150411
12 beta20150411 app-shells/rust-zshcomp 1_beta20150411
12 beta20150411 app-emacs/rust-mode 1_beta20150411
11 pre20161029 media-sound/tomahawk 0.9.0_pre20161029

Key|Ct  (Pct)    Histogram
 9|299 (24.67%) ********************************************************
11|208 (17.16%) ***************************************
 2|197 (16.25%) *************************************
 3|168 (13.86%) *******************************
 5|144 (11.88%) ***************************
 4| 96  (7.92%) ******************
 6| 38  (3.14%) *******
 7| 33  (2.72%) *******
 8|  9  (0.74%) **
13|  7  (0.58%) **
17|  4  (0.33%) *
15|  4  (0.33%) *
12|  3  (0.25%) *
10|  2  (0.17%) *

The situation is similar to numeric components. The longest components
are various kinds of timestamps, increased by appropriate keyword
lengths. (note: actually, all those should be +1 since I didn't count
the '_').


=== Version suffix counts ===
There are no more than 2 suffixes used in versions simultaneously.
The packages using two suffixes are:

_beta_p dev-java/protobuf-java 3.0.0_beta3_p1
_beta_p dev-libs/protobuf 3.0.0_beta3_p1
_beta_p dev-python/protobuf-python 3.0.0_beta3_p1
_beta_p dev-util/xxdiff 4.0_beta1_p20110426
_beta_p net-analyzer/fping 2.4_beta2_p161
_beta_p net-misc/fatrat 1.2.0_beta2_p20150803
_beta_p net-misc/freerdp 1.1.0_beta1_p20130710
_beta_p x11-plugins/wmtime 1.0_beta2_p9
_p_p net-analyzer/tcptrace 6.6.7_p4_p1
_p_p x11-libs/xosd 2.2.14_p2_p1
_p_p x11-misc/xkbset 0.5_p5_p1
_pre_p app-arch/unp 2.0_pre7_p1
_pre_p x11-misc/imwheel 1.0.0_pre13_p20100827
_rc_p dev-libs/hidapi 0.8.0_rc1_p20140719
_rc_p dev-lua/busted 2.0_rc11_p0
_rc_p dev-lua/busted 2.0_rc12_p1
_rc_p media-libs/openglide 0.09_rc9_p20160913

    Key|Ct (Pct)    Histogram
_beta_p|8 (44.44%) *****************************************************
  _rc_p|4 (22.22%) ***************************
 _pre_p|3 (16.67%) ********************
   _p_p|3 (16.67%) ********************

It seems that double suffixes are used to either indicate snapshots of
corresponding upstream versions, or to cover non-Gentoo-friendly
versions such as '6.6.7-4.1'.

Note: there is also a pathological case of bash-4.3_p39_pre0 that is
non-keyworded. In this case, it seems that -pre0 doesn't correspond to
any upstream version.


== Policy changes? ==
I think that the following new policies could make sense:

1. Revision number must be no longer than 9999:
1a. to make <=X-r9999 reliable,
1b. to prevent pathological uses of revision as date.

2. I think we could use a policy to make >=X_alpha reliable. However, I
have no clue how to word it without making it weird and artificially
restricting valid version numbers.

What do you think?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Rich Freeman]

On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> 1. Revision number must be no longer than 9999:
> 1a. to make <=X-r9999 reliable,
> 1b. to prevent pathological uses of revision as date.
>

Let's just hope nobody starts using tex version numbering and so on.
Dates might be used in cases where upstream doesn't publish sane
revisions (in fact, texlive versions are dates, albeit at the year
level).

I'm not saying this isn't a good idea, I just could see where it might
crash into reality at some point.

-- 
Rich

Re: [gentoo-dev] Revisiting version-related tree policies

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 805 bytes --]

On 03/11/16 01:20 PM, Rich Freeman wrote:
> On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> 1. Revision number must be no longer than 9999:
>> 1a. to make <=X-r9999 reliable,
>> 1b. to prevent pathological uses of revision as date.
>>
> 
> Let's just hope nobody starts using tex version numbering and so on.
> Dates might be used in cases where upstream doesn't publish sane
> revisions (in fact, texlive versions are dates, albeit at the year
> level).
> 
> I'm not saying this isn't a good idea, I just could see where it might
> crash into reality at some point.
> 

This is just the revision portion though, that's not part of the
version number from upstream.  IIRC, the revision is meant to only be
used for gentoo ebuild changes, isn't it?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Rich Freeman]

On Thu, Nov 3, 2016 at 1:44 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> On 03/11/16 01:20 PM, Rich Freeman wrote:
>>
>> Let's just hope nobody starts using tex version numbering and so on.
>> Dates might be used in cases where upstream doesn't publish sane
>> revisions (in fact, texlive versions are dates, albeit at the year
>> level).
>>
>> I'm not saying this isn't a good idea, I just could see where it might
>> crash into reality at some point.
>>
>
> This is just the revision portion though, that's not part of the
> version number from upstream.  IIRC, the revision is meant to only be
> used for gentoo ebuild changes, isn't it?
>

Correct, I intended to comment on the version, not revision.  However,
the 18 digit limit could still become an issue there with pathological
cases like Tex (which basically communicates 1 bit of information in
each digit it adds).  I still don't think it makes sense to design
things around seemingly-clever converging numbering schemes.

-- 
Rich

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

>>>>> On Thu, 3 Nov 2016, Michał Górny wrote:

> == Policy changes? ==
> I think that the following new policies could make sense:

> 1. Revision number must be no longer than 9999:
> 1a. to make <=X-r9999 reliable,
> 1b. to prevent pathological uses of revision as date.

I think that we should consider restricting revisions to 4 digits.
Real revisions (i.e., counted up from r0) in the tree seem to end
somewhere around r30. Even with r100, r200 for different slots, a
limit of 9999 shouldn't pose any problems. For date based versions,
_pre or _p should be used, but not revisions.

Note that this would be tree policy only (similar as the maximum
length of 18 digits for version components is), but _not_ a
restriction to be put in PMS.

> 2. I think we could use a policy to make >=X_alpha reliable.
> However, I have no clue how to word it without making it weird and
> artificially restricting valid version numbers.

Or rules concerning multiple suffixes are simple and straight forward,
and they don't appear to be abused. Therefore, I would leave them
alone.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]

On 11/03/2016 05:11 PM, Michał Górny wrote:
> == Policy changes? ==
> I think that the following new policies could make sense:
> 
> 1. Revision number must be no longer than 9999:

You likely mean "no higher than 9999", longer than would give large values

> 1a. to make <=X-r9999 reliable,
> 1b. to prevent pathological uses of revision as date.

Given revision in most cases is incremental (except for some -r100,
-r200) cases, some structure here is likely good. I take it we're
talking about devmanual changes in this case for policy?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Thu, 3 Nov 2016 17:11:22 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> 1. Revision number must be no longer than 9999:
> 1a. to make <=X-r9999 reliable,
> 1b. to prevent pathological uses of revision as date.

I think most the arguments you've made for this stem from subjective
and social problems, not technical ones.

I'd hate to be artificially limiting the utility of what can be done
with "-r" versions just because *some* of those versions *may* be
confusing for humans.

I could just as easily argue that using -r200 and -r300 is "confusing",
and that 1.2r-300 "could be a problem" and maybe we should abolish
-r'vs entirely.

The -r200 and -r300 were also not just arbitrary numbers, but they
followed the slot version, and so the "-r" suffix was itself not purely
a "X < Y", but also conveyed data about what it was for, and served as
a predictable anti-collision mechanism ( due to the whole
2-slots-cant-have-identical-versions deal )

And as you know I was considering a similar strategy to be able to have
several variations of the same perl virtual for upgrade reasons, but
that would predictably have a much wider variety of '-r ' prefixes to
represent the wider variety of significant Perl versions. 



> 2. I think we could use a policy to make >=X_alpha reliable. However,
> I have no clue how to word it without making it weird and artificially
> restricting valid version numbers.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

>>>>> On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote:

> On 11/03/2016 05:11 PM, Michał Górny wrote:
>> == Policy changes? ==
>> I think that the following new policies could make sense:
>> 
>> 1. Revision number must be no longer than 9999:

> You likely mean "no higher than 9999", longer than would give large
> values

The wording would be similar to "no longer than 4 digits".

>> 1a. to make <=X-r9999 reliable,
>> 1b. to prevent pathological uses of revision as date.

> Given revision in most cases is incremental (except for some -r100,
> -r200) cases, some structure here is likely good. I take it we're
> talking about devmanual changes in this case for policy?

Yes, it would be purely devmanual/tree policy. PMS will still mandate
that the package manager can handle arbitrary long versions.

Looks like using multiples of 100 is best practice if there is
the same PV in different slots. Not sure if we should codify that
somewhere. (If nobody contradicts, this message could be used as
future policy reference, though. :)

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

>>>>> On Fri, 4 Nov 2016, Kent Fredric wrote:

>> 1. Revision number must be no longer than 9999:
>> 1a. to make <=X-r9999 reliable,
>> 1b. to prevent pathological uses of revision as date.

> I think most the arguments you've made for this stem from subjective
> and social problems, not technical ones.

Exactly. That's why this is not intended for PMS but for the
devmanual. Developer time is one of our most valuable resources.

> I'd hate to be artificially limiting the utility of what can be done
> with "-r" versions just because *some* of those versions *may* be
> confusing for humans.

> I could just as easily argue that using -r200 and -r300 is
> "confusing", and that 1.2r-300 "could be a problem" and maybe we
> should abolish -r'vs entirely.

> The -r200 and -r300 were also not just arbitrary numbers, but they
> followed the slot version, and so the "-r" suffix was itself not
> purely a "X < Y", but also conveyed data about what it was for, and
> served as a predictable anti-collision mechanism ( due to the whole
> 2-slots-cant-have-identical-versions deal )

I think nobody is arguing against using r200 etc. for special
purposes.

> And as you know I was considering a similar strategy to be able
> to have several variations of the same perl virtual for upgrade
> reasons, but that would predictably have a much wider variety of
> '-r ' prefixes to represent the wider variety of significant Perl
> versions.

I would assume 9999 to be high enough, even if you use multiples of
100 to label the slot. Or do you expect having more than 100 slots for
Perl?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Fri, 4 Nov 2016 10:24:28 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> I would assume 9999 to be high enough, even if you use multiples of
> 100 to label the slot. Or do you expect having more than 100 slots for
> Perl?

Well, the desire is for the -r<x> (or similar) part correspond to
something representative of which version of Perl the virtual is an
"underwriter" for.

So it would naturally start at one of the following:

 522, 524, 526
 5022, 5024, 5026

And then you realise upstream are getting crazy and you'll need a
seperate virtual only for 5.22.1, so you'll need

 -r5221

But that's only enough for a prefix for the identifier ... so you'll want -r52210, -r52211, 

and at this point, it very much is getting into the weeds of confusing.

Granted I'm still at "worry about things that aren't actually a problem yet" stage.

Mostly because we're not yet employing this technique until we're sure
its going to be a good idea, and the only place we've *kinda* needed
such a solution is virtual/perl-Test-Simple
( https://bugs.gentoo.org/show_bug.cgi?id=584238#c11 )

The problem however is reduced as follows:

1. Slots are not appropriate, because they can't be concurrently installed
2. versions must indicate an upgrade path to coerce portage to install
   and remove things as needed
3. versions on the virtual themselves must correlate with upstream,
   because we use the virtuals to ensure "X version of Y exists somehow"

and the /desire/ is to have an -r<x> scheme that we could consider
making automated one day.

There's just not a lot of wiggle room, because most of PV is "upstreams
version", and the '-r<x>' part is really the only part we can have some
flexibility with.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

>>>>> On Sat, 5 Nov 2016, Kent Fredric wrote:

>> I would assume 9999 to be high enough, even if you use multiples of
>> 100 to label the slot. Or do you expect having more than 100 slots
>> for Perl?

> Well, the desire is for the -r<x> (or similar) part correspond to
> something representative of which version of Perl the virtual is an
> "underwriter" for.

This would contradict existing policy already, which says that the
revision component must not be used for upstream versions:
https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

On Sat, 5 Nov 2016 11:13:35 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> revision component must not be used for upstream versions:

The problem is we have *2* upstream versions.

 virtual/perl-Foo-N

Maps to

  perl-core/Foo-N

And

  dev-lang/perl-Y ( for possibly more than one value of Y )

And Y does not equal N

Presently, this is "not a problem", because there is only 1 of each "N"
for virtual/perl-Foo-N

And it maps with this horrible magic of

  || ( =dev-lang/perl-Y4* =dev-lang/perl-Y3* =dev-lang/perl-Y2* ~perl-core/Foo-N )
  !<perl-core/Foo-N
  !>perl-core/Foo-N-r999

Which is "logically correct", however, as seen in bug #584238[1],
portage does not always do the right thing, and it makes a real mess of
things having one package virtualising multiple different keywords. ( I
had to get into graphing tools to work out what the hell was actually
happening )

*especially* in cases where we need to indicate an "upstream merge in a virtual" as with 584238

So the strategy that I was considering was to "split" each logical upstream virtual into several pieces:

  virtual/perl-Foo-N  to virtual/perl-Foo-N-r99 : "Always pull perl core/*"

  virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 5.22 and remove perl-core/*"

  virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 5.24 and remove perl-core/*"


Which allows us to control which outcome a user gets by keeping keywords consistent across the board, as
we'd stabilize/keyword all '-r522**' with perl 5.22

  virtual/perl-Foo-N to virtual/perl-Foo-N-r99

would thus be "Getting multiprovided things at newer versions than is available in your shipped perl", and that
-r range would only be stabilized to fast-track security issues or to provide those versions for dependents
before the respective perl is stabilized ( that is, the fallback to perl-core is done with maximum reluctance )

This idea was hoped to be more predictable than a monolithic virtual
that had all those outcomes as possibilities which then caused portage to be confused.
 
( I hope this explanation is more clear than the last one, but its OK
if you're still confused, it took me a few weeks to get my head around
it the first time, but I implore you to read the related bug and pay
careful attention to its attached images )

1: https://bugs.gentoo.org/show_bug.cgi?id=584238

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

>>>>> On Sun, 6 Nov 2016, Kent Fredric wrote:

> So the strategy that I was considering was to "split" each logical
> upstream virtual into several pieces:

>   virtual/perl-Foo-N  to virtual/perl-Foo-N-r99 : "Always pull perl core/*"

>   virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 5.22 and remove perl-core/*"

>   virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 5.24 and remove perl-core/*"

I still don't see why you must (ab)use the revision for that. With
virtuals, the whole PV is at your disposal, so you could append .5.22
to it, or even use a suffix like _p522.

The purpose of the revision is really for incremental changes of the
ebuild within one upstream version. About the only situation where
using large steps (like 100) in revision numbers is justified is when
ebuilds in different slots would otherwise collide.

> This idea was hoped to be more predictable than a monolithic virtual
> that had all those outcomes as possibilities which then caused
> portage to be confused.

Really, if it is a portage bug then that should be fixed, instead of
inventing complicated schemes to work around it.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Sat, 5 Nov 2016 12:43:31 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> I still don't see why you must (ab)use the revision for that. With
> virtuals, the whole PV is at your disposal, so you could append .5.22
> to it, or even use a suffix like _p522.

Incidentally, I did use _p522 for the one case we had pressing need to do this
immediately.

And shortly after I fell afoul of the whole "used ~ when I should have
used =ATOM*" thing, and then was told we shouldn't use "_p" because it
was supposed to reflect "upstream patching" not "gentoo patching",
because "gentoo stuff" is supposed to be "-r"

The only reason I'm terrified of using "The whole space" is because its
too hard to anticipate what upstream will do tomorrow.

_p<x> was the only place I was safe without the concern that upstream could somehow
make life hard for everyone.

Because If we put

  =virtual/perl-Foo-0.13.0.522

In tree, luck would have it upstream would decide to ship "Foo
0.13.0.10" a week later, and we'd be in a fun "downgrade to upgrade" hell.

> The purpose of the revision is really for incremental changes of the
> ebuild within one upstream version.

Well, this is sort of what I'm mentally trying to do really.

Because all versions upstream could make next are "legal", I'm trying to stand
between this version, and smallest possible increment upstream could conceivably make.

It does seem paranoid overall, but I've seen my share of horrors with
upstream special-snowflaking versions that the overall desire is to
treat $PV as a black box (with normalisation) which Gentoo doesn't have
any interference with.

> About the only situation where using large steps (like 100) in
> revision numbers is justified is when ebuilds in different slots
> would otherwise collide.

Maybe we need another token legal in PV,

  _gentoo[0-9]+

?

Then GTK and friends could use

    1.23.4_gentoo2-r1 
    1.23.4_gentoo3-r1 

And Perl virtuals would be 

    perl-Foo, perl-Foo-r1, perl-Foo_gentoo522, perl-Foo_gentoo522-r1


Where

    1.0.0 < 1.0.0_gentoo1 < 1.0.0_p1 < 1.0.0_p1_gentoo1 

_gentoo is of course just a placeholder for which many bike sheds can
be painted for naming.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Revisiting version-related tree policies

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Le vendredi 04 novembre 2016 à 10:16 +0100, Ulrich Mueller a écrit :
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote:
> 
> > 
> > On 11/03/2016 05:11 PM, Michał Górny wrote:
> > > 
> > > == Policy changes? ==
> > > I think that the following new policies could make sense:
> > > 
> > > 1. Revision number must be no longer than 9999:
> 
> > 
> > You likely mean "no higher than 9999", longer than would give large
> > values
> 
> The wording would be similar to "no longer than 4 digits".
> 
> > 
> > > 
> > > 1a. to make <=X-r9999 reliable,
> > > 1b. to prevent pathological uses of revision as date.
> 
> > 
> > Given revision in most cases is incremental (except for some -r100,
> > -r200) cases, some structure here is likely good. I take it we're
> > talking about devmanual changes in this case for policy?
> 
> Yes, it would be purely devmanual/tree policy. PMS will still mandate
> that the package manager can handle arbitrary long versions.
> 
> Looks like using multiples of 100 is best practice if there is
> the same PV in different slots. Not sure if we should codify that
> somewhere. (If nobody contradicts, this message could be used as
> future policy reference, though. :)

There was much contradiction when this was "discovered" being used in
webkit-gtk ebuilds back when slot 3 was added. However, I don't
remember anyone reaching a solution that would be practical keeping
only one cat/pn.

-- 
Gilles Dartiguelongue <eva@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 216 bytes --]