[[PATCH setup] 0/3] Prepare for colons in version numbers

[[PATCH setup] 0/3] Prepare for colons in version numbers

[Ken Brown]

A future version of setup might allow version numbers of the form
e:v-r, where is an epoch.  Currently setup doesn't parse these
correctly when reading installed.db.  In case ScanFindVisitor is used,
there is an additional problem in reading filenames containing colons.
The reading is done by Win32 functions, and the illegal characters
like ':' aren't translated.

Ken Brown (3):
  Remove the function filemanip.cc:base
  Bump the installed.db version to 4
  Remove the ScanFindVisitor class

 IniDBBuilderPackage.h |  6 ------
 Makefile.am           |  2 --
 ScanFindVisitor.cc    | 57 ---------------------------------------------------
 ScanFindVisitor.h     | 36 --------------------------------
 filemanip.cc          | 18 +---------------
 filemanip.h           |  1 -
 fromcwd.cc            |  8 +-------
 package_db.cc         | 19 +++++++++--------
 8 files changed, 13 insertions(+), 134 deletions(-)
 delete mode 100644 ScanFindVisitor.cc
 delete mode 100644 ScanFindVisitor.h

-- 
2.14.2

[[PATCH setup] 3/3] Remove the ScanFindVisitor class

[Ken Brown]

This class was used for local installs in which the repository
contains no setup.ini file.  It didn't correctly handle filenames with
colons, and it could become a maintenance burden to continue to
support it.  There are now good instructions at
https://cygwin.com/package-server.html#overlay for creating a valid
repository, so we just remove the class instead of fixing it.
---
 IniDBBuilderPackage.h |  6 ------
 Makefile.am           |  2 --
 ScanFindVisitor.cc    | 57 ---------------------------------------------------
 ScanFindVisitor.h     | 36 --------------------------------
 fromcwd.cc            |  8 +-------
 5 files changed, 1 insertion(+), 108 deletions(-)
 delete mode 100644 ScanFindVisitor.cc
 delete mode 100644 ScanFindVisitor.h

diff --git a/IniDBBuilderPackage.h b/IniDBBuilderPackage.h
index 766a5ef..323b186 100644
--- a/IniDBBuilderPackage.h
+++ b/IniDBBuilderPackage.h
@@ -42,12 +42,6 @@ public:
   void buildPackageSource (const std::string&, const std::string&,
                            char *, hashType);
 
-  // helpers for ScanFindVisitor
-  void buildPackageInstall (const std::string& path, const std::string& size)
-  { buildPackageInstall(path, size, NULL, hashType::none); }
-  void buildPackageSource (const std::string& path, const std::string& size)
-  { buildPackageSource(path, size, NULL, hashType::none); }
-
   void buildPackageTrust (int);
   void buildPackageCategory (const std::string& );
 
diff --git a/Makefile.am b/Makefile.am
index d4c8472..7d1f072 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -236,8 +236,6 @@ inilint_SOURCES = \
 	resource.h \
 	root.cc \
 	root.h \
-	ScanFindVisitor.cc \
-	ScanFindVisitor.h \
 	script.cc \
 	script.h \
 	setup_version.h \
diff --git a/ScanFindVisitor.cc b/ScanFindVisitor.cc
deleted file mode 100644
index 14c3722..0000000
--- a/ScanFindVisitor.cc
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * Copyright (c) 2002 Robert Collins.
- *
- *     This program is free software; you can redistribute it and/or modify
- *     it under the terms of the GNU General Public License as published by
- *     the Free Software Foundation; either version 2 of the License, or
- *     (at your option) any later version.
- *
- *     A copy of the GNU General Public License can be found at
- *     http://www.gnu.org/
- *
- * Written by Robert Collins <robertc@hotmail.com>
- *
- */
-
-#include "ScanFindVisitor.h"
-#include "filemanip.h"
-#include "IniDBBuilderPackage.h"
-
-ScanFindVisitor::ScanFindVisitor(IniDBBuilderPackage &aBuilder) : _Builder (aBuilder) {}
-ScanFindVisitor::~ScanFindVisitor(){}
-
-/* look for potential packages we can add to the in-memory package
- * database
- */
-void
-ScanFindVisitor::visitFile(const std::string& basePath,
-                           const WIN32_FIND_DATA *theFile)
-{
-  // Sanity check: Does the file look like a package ?
-  fileparse f;
-  if (!parse_filename (theFile->cFileName, f))
-    return;
-
-  // Sanity check: Zero length package files get thrown out.
-  if (!(theFile->nFileSizeLow || theFile->nFileSizeHigh))
-    return;
-
-  // Build a new package called f.pkg
-  _Builder.buildPackage (f.pkg);
-
-  // Set the version we are bulding
-  _Builder.buildPackageVersion (f.ver);
-
-  // Add the file as a installable package
-  if (!f.what.size())
-    {
-      //assume binary
-      _Builder.buildPackageInstall (basePath + theFile->cFileName,
-                                    stringify(theFile->nFileSizeLow));
-    }
-  else
-    // patch or src, assume src until someone complains
-    _Builder.buildPackageSource (basePath + theFile->cFileName,
-                                 stringify(theFile->nFileSizeLow));
-
-}
diff --git a/ScanFindVisitor.h b/ScanFindVisitor.h
deleted file mode 100644
index b4c93d9..0000000
--- a/ScanFindVisitor.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Copyright (c) 2002 Robert Collins.
- *
- *     This program is free software; you can redistribute it and/or modify
- *     it under the terms of the GNU General Public License as published by
- *     the Free Software Foundation; either version 2 of the License, or
- *     (at your option) any later version.
- *
- *     A copy of the GNU General Public License can be found at
- *     http://www.gnu.org/
- *
- * Written by Robert Collins <robertc@hotmail.com>
- *
- */
-
-#ifndef SETUP_SCANFINDVISITOR_H
-#define SETUP_SCANFINDVISITOR_H
-
-#include "FindVisitor.h"
-
-class IniDBBuilderPackage ;
-/* Scan files and create a package db when no cached .ini exists */
-class ScanFindVisitor : public FindVisitor
-{
-public:
-  ScanFindVisitor (IniDBBuilderPackage &aBuilder);
-  virtual void visitFile(const std::string& basePath, const WIN32_FIND_DATA *);
-  virtual ~ ScanFindVisitor ();
-protected:
-  ScanFindVisitor (ScanFindVisitor const &);
-  ScanFindVisitor & operator= (ScanFindVisitor const &);
-private:
-  IniDBBuilderPackage &_Builder;
-};
-
-#endif /* SETUP_SCANFINDVISITOR_H */
diff --git a/fromcwd.cc b/fromcwd.cc
index 791744e..3e77ad3 100644
--- a/fromcwd.cc
+++ b/fromcwd.cc
@@ -30,7 +30,7 @@
 #include "find.h"
 #include "ini.h"
 
-#include "ScanFindVisitor.h"
+#include "FindVisitor.h"
 #include "IniDBBuilderPackage.h"
 #include "IniParseFeedback.h"
 
@@ -111,7 +111,6 @@ IniList found_ini_list;
 bool
 do_from_local_dir (HINSTANCE h, HWND owner, std::string &local_dir)
 {
-  // Assume we won't find the INI file.
   SetupFindVisitor found;
   // single mirror?
   Find (local_dir.c_str ()).accept (found, 1);
@@ -121,10 +120,5 @@ do_from_local_dir (HINSTANCE h, HWND owner, std::string &local_dir)
   Find (local_dir.c_str ()).accept (found, 2);
   if (found)
       return true;
-  // nope, do full scan.
-  IniParseFeedback myFeedback;
-  IniDBBuilderPackage myBuilder (myFeedback);
-  ScanFindVisitor myVisitor (myBuilder);
-  Find (local_dir.c_str ()).accept (myVisitor);
   return false;
 }
-- 
2.14.2

[[PATCH setup] 2/3] Bump the installed.db version to 4

[Ken Brown]

Starting with the commit 'Remove the function filemanip.cc:base',
setup correctly parses version numbers of the form e:v-r in
installed.db.  Bump the version of installed.db to reflect the fact
that older setup doesn't parse filenames containing colons correctly.
---
 package_db.cc | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/package_db.cc b/package_db.cc
index dbec17e..c108757 100644
--- a/package_db.cc
+++ b/package_db.cc
@@ -70,7 +70,7 @@ packagedb::packagedb ()
 
 	  Log (LOG_BABBLE) << "INSTALLED.DB version " << dbver << endLog;
 
-	  if (dbver <= 3)
+	  if (dbver <= 4)
 	    {
 	      char inst[1000];
 
@@ -113,7 +113,7 @@ packagedb::packagedb ()
 		  pkg->set_installed (binary);
 		  pkg->desired = pkg->installed;
 
-		  if (dbver == 3)
+		  if (dbver >= 3)
 		    pkg->user_picked = (user_picked & 1);
 		}
 	      delete db;
@@ -144,7 +144,7 @@ packagedb::flush ()
   if (!ndb)
     return errno ? errno : 1;
 
-  ndb->write ("INSTALLED.DB 3\n", strlen ("INSTALLED.DB 3\n"));
+  ndb->write ("INSTALLED.DB 4\n", strlen ("INSTALLED.DB 4\n"));
   for (packagedb::packagecollection::iterator i = packages.begin ();
        i != packages.end (); ++i)
     {
@@ -152,10 +152,13 @@ packagedb::flush ()
       if (pkgm.installed)
 	{
 	  /*
-	    In INSTALLED.DB 3, lines are: 'packagename version flags', where
-	    version is encoded in a notional filename for backwards
-	    compatibility, and the only currently defined flag is user-picked
-	    (bit 0).
+	    Starting with INSTALLED.DB 3, lines are: 'packagename
+	    version flags', where version is encoded in a notional
+	    filename for backwards compatibility, and the only
+	    currently defined flag is user-picked (bit 0).  Starting
+	    with INSTALLED.DB 4, the version number can have the form
+	    e:v-r; earlier versions of setup will skip past the colon
+	    and not parse this correctly.
 	  */
 	  std::string line;
 	  line = pkgm.name + " " +
@@ -182,7 +185,7 @@ packagedb::upgrade()
       /* Guess which packages were user_picked.  This has to take place after
          setup.ini has been parsed as it needs dependency information. */
       guessUserPicked();
-      installeddbver = 3;
+      installeddbver = 4;
     }
 }
 
-- 
2.14.2

[[PATCH setup] 1/3] Remove the function filemanip.cc:base

[Ken Brown]

This was called only on plain filenames, not full pathnames, so it was
not needed.  Moreover, it wasn't correctly handling filenames
containing colons.
---
 filemanip.cc | 18 +-----------------
 filemanip.h  |  1 -
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/filemanip.cc b/filemanip.cc
index d1d27be..265a2a7 100644
--- a/filemanip.cc
+++ b/filemanip.cc
@@ -43,22 +43,6 @@ get_file_size (const std::string& name)
   return rv;
 }
 
-std::string 
-base (const std::string& aString)
-{
-  if (!aString.size())
-    return "";
-  const char *s = aString.c_str();
-  std::string rv = s;
-  while (*s)
-    {
-      if ((*s == '/' || *s == ':' || *s == '\\') && s[1])
-	rv = s + 1;
-      s++;
-    }
-  return rv;
-}
-
 /* returns the number of characters of path that
  * precede the extension
  */
@@ -89,7 +73,7 @@ parse_filename (const string &fn, fileparse & f)
 
   f.tail = fn.substr (n, string::npos);
 
-  p = new_cstr_char_array (base (fn.substr (0, n)));
+  p = new_cstr_char_array (fn.substr (0, n));
   char const *ext;
   /* TODO: make const and non-const trail variant. */
   if ((ext = trail (p, "-src")))
diff --git a/filemanip.h b/filemanip.h
index 5594519..451211f 100644
--- a/filemanip.h
+++ b/filemanip.h
@@ -30,7 +30,6 @@ struct fileparse
 };
 
 int parse_filename (const std::string& fn, fileparse & f);
-std::string base (const std::string& );
 size_t get_file_size (const std::string& );
 std::string backslash (const std::string& s);
 const char * trail (const char *, const char *);
-- 
2.14.2

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Achim Gratz]

Ken Brown writes:
> A future version of setup might allow version numbers of the form
> e:v-r, where is an epoch.  Currently setup doesn't parse these
> correctly when reading installed.db.  In case ScanFindVisitor is used,
> there is an additional problem in reading filenames containing colons.
> The reading is done by Win32 functions, and the illegal characters
> like ':' aren't translated.

I don't really think it's worth anybody's while to introduce support for
a feature (epochs) that everone else decided should not be used.  Do we
really want to use epochs and what for?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Ken Brown]

On 10/27/2017 3:26 PM, Achim Gratz wrote:
> Ken Brown writes:
>> A future version of setup might allow version numbers of the form
>> e:v-r, where is an epoch.  Currently setup doesn't parse these
>> correctly when reading installed.db.  In case ScanFindVisitor is used,
>> there is an additional problem in reading filenames containing colons.
>> The reading is done by Win32 functions, and the illegal characters
>> like ':' aren't translated.
> 
> I don't really think it's worth anybody's while to introduce support for
> a feature (epochs) that everone else decided should not be used.  Do we
> really want to use epochs and what for?

The libsolv branch already supports them.  That was my motivation for 
these changes.

Ken

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Brian Inglis]

On 2017-10-27 13:26, Achim Gratz wrote:
> Ken Brown writes:
>> A future version of setup might allow version numbers of the form
>> e:v-r, where is an epoch.  Currently setup doesn't parse these
>> correctly when reading installed.db.  In case ScanFindVisitor is used,
>> there is an additional problem in reading filenames containing colons.
>> The reading is done by Win32 functions, and the illegal characters
>> like ':' aren't translated.
> 
> I don't really think it's worth anybody's while to introduce support for
> a feature (epochs) that everone else decided should not be used.  Do we
> really want to use epochs and what for?

Possibly yes, to avoid users having to manually select upgraded versions, as
when package upstream version numbering changes from say yyyymmdd to v.m.r or
vice versa or something completely different, the higher epoch (original default
is 0:) says this is an upgrade regardless of the rest of the upstream version;
see https://www.debian.org/doc/debian-policy/#version

An alternative could be: upgrade if installed != current, allowing for
downgrades when bugs occur, but presumably this has been discussed before.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Yaakov Selkowitz]

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

On 2017-10-27 14:26, Achim Gratz wrote:
> Ken Brown writes:
>> A future version of setup might allow version numbers of the form
>> e:v-r, where is an epoch.  Currently setup doesn't parse these
>> correctly when reading installed.db.  In case ScanFindVisitor is used,
>> there is an additional problem in reading filenames containing colons.
>> The reading is done by Win32 functions, and the illegal characters
>> like ':' aren't translated.
> 
> I don't really think it's worth anybody's while to introduce support for
> a feature (epochs) that everone else decided should not be used.  Do we
> really want to use epochs and what for?

On the contrary, I have argued that we *do* need epoch to deal with
occasions where versions go backwards.  I did however say that I wasn't
keen on using them to work around CPAN's unique versioning issues, as it
may inflate quickly in that particular scenario.

-- 
Yaakov


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

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Jon Turney]

On 27/10/2017 19:47, Ken Brown wrote:
> A future version of setup might allow version numbers of the form
> e:v-r, where is an epoch.  Currently setup doesn't parse these
> correctly when reading installed.db.  In case ScanFindVisitor is used,
> there is an additional problem in reading filenames containing colons.
> The reading is done by Win32 functions, and the illegal characters
> like ':' aren't translated.
> 
> Ken Brown (3):
>    Remove the function filemanip.cc:base
>    Bump the installed.db version to 4
>    Remove the ScanFindVisitor class

Great, thanks.

I'll hold 2/3 back a bit, as bumping the installed.db version makes it a 
pain to go back to the released setup version after testing...

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Jon Turney]

On 27/10/2017 20:26, Achim Gratz wrote:
> Ken Brown writes:
>> A future version of setup might allow version numbers of the form
>> e:v-r, where is an epoch.  Currently setup doesn't parse these
>> correctly when reading installed.db.  In case ScanFindVisitor is used,
>> there is an additional problem in reading filenames containing colons.
>> The reading is done by Win32 functions, and the illegal characters
>> like ':' aren't translated.
> 
> I don't really think it's worth anybody's while to introduce support for
> a feature (epochs) that everone else decided should not be used. 

"everyone" != "everyone, ignoring people who disagree with me"

If you think epochs are a bad idea, you need to give reasons, not just 
pretend there is no debate.

I agree it does not work well for CPAN-style floating point version 
numbers, but that's your problem to solve, or not, however you like...

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Achim Gratz]

Am 30.10.2017 um 16:58 schrieb Jon Turney:
> "everyone" != "everyone, ignoring people who disagree with me"

I think this is an unfair summary of my position.

> If you think epochs are a bad idea, you need to give reasons, not just 
> pretend there is no debate.

I was strictly talking about those folks who've had the opportunity in 
practise so far, which is all the major GNU/Linux distributions.  The 
ones I'm aware of aren't using epochs and instead decided to use other 
means of achieving the same (or similar) goals.  In fact they created 
rules to not use epochs even though the tools support them.  Their line 
of reasoning always was (and still is), that once you start using epochs 
there is no way going back and you could just as well have used 
monotonic release numbers instead of versions.  The other point is that 
it is close to impossible that everybody will agree on what the epoch 
ought to be.  The last point is that once an epoch bump is introduced, 
you can't decide to sort things differently unless you're prepared to 
invalidate all existing released packages.

So, we might have that debate now for Cygwin because we might finally 
use a library that supports epochs, but others have been there before us 
and concluded that epochs aren't worth the trouble.  I don't see our 
situation with Cygwin different enough to come to a different conclusion 
than the distro folks and they've had many more brains to pick on this 
issue.

> I agree it does not work well for CPAN-style floating point version 
> numbers, but that's your problem to solve, or not, however you like...

You can stop using this particular example if it helps you not taking a 
right at Albuquerque each time version numbers come up.  This is just 
one of many examples where two sets of sane versioning rules don't 
produce the same ordering.

There are plenty of other examples where versioning upstream for 
whatever reason doesn't conform to whatever set of rules to make them 
sortable and it's not all that unheard of that upstream decides to 
change their rules once in a while even if they otherwise keep their stride.

So whatever the reason, you will have to impose a sort order whenever 
there is a package that doesn't follow the rules builtin to setup and 
hence sorts incorrectly.  You say epochs are _the_ way to do that and 
I'm pointing out that the distro folks have come to the conclusion that 
it isn't and are using different mechanisms.

-- 
Achim.

(on the road :-)

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Corinna Vinschen]

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

On Oct 31 11:06, Achim Gratz wrote:
> Am 30.10.2017 um 16:58 schrieb Jon Turney:
> > "everyone" != "everyone, ignoring people who disagree with me"
> 
> I think this is an unfair summary of my position.
> 
> > If you think epochs are a bad idea, you need to give reasons, not just
> > pretend there is no debate.
> 
> I was strictly talking about those folks who've had the opportunity in
> practise so far, which is all the major GNU/Linux distributions.  The ones
> I'm aware of aren't using epochs and instead decided to use other means of
> achieving the same (or similar) goals.  In fact they created rules to not
> use epochs even though the tools support them.  Their line of reasoning
> always was (and still is), that once you start using epochs there is no way
> going back and you could just as well have used monotonic release numbers
> instead of versions.  The other point is that it is close to impossible that
> everybody will agree on what the epoch ought to be.  The last point is that
> once an epoch bump is introduced, you can't decide to sort things
> differently unless you're prepared to invalidate all existing released
> packages.

Not sure what distros you're referring to.  Of the 58467 packages
in Fedora 26, 7822 are using epochs.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Brian Inglis]

On 2017-10-31 05:21, Corinna Vinschen wrote:
> On Oct 31 11:06, Achim Gratz wrote:
>> Am 30.10.2017 um 16:58 schrieb Jon Turney:
>>> "everyone" != "everyone, ignoring people who disagree with me"
>>
>> I think this is an unfair summary of my position.
>>
>>> If you think epochs are a bad idea, you need to give reasons, not just
>>> pretend there is no debate.
>>
>> I was strictly talking about those folks who've had the opportunity in
>> practise so far, which is all the major GNU/Linux distributions.  The ones
>> I'm aware of aren't using epochs and instead decided to use other means of
>> achieving the same (or similar) goals.  In fact they created rules to not
>> use epochs even though the tools support them.  Their line of reasoning
>> always was (and still is), that once you start using epochs there is no way
>> going back and you could just as well have used monotonic release numbers
>> instead of versions.  The other point is that it is close to impossible that
>> everybody will agree on what the epoch ought to be.  The last point is that
>> once an epoch bump is introduced, you can't decide to sort things
>> differently unless you're prepared to invalidate all existing released
>> packages.
> 
> Not sure what distros you're referring to.  Of the 58467 packages
> in Fedora 26, 7822 are using epochs.

At ~13% that's a bit higher than Ubuntu/Debian Trusty with 5056/48423 ~10%.
It does not appear that either of those bases use the epoch in the package
archive names, only in the package manager.
That may be the way to go - don't use the epoch field in the package archive name.
If the epochs differ - the package versions are totally different in some way.
If they are the same epoch, the packages are correctly ordered by a version
sort, as supported in sort, ls, etc.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Achim Gratz]

Am 31.10.2017 um 12:21 schrieb Corinna Vinschen:
> Not sure what distros you're referring to.  Of the 58467 packages
> in Fedora 26, 7822 are using epochs.

I'm expecting as much since it was rpm that introduced the epoch IIRC (I 
think an earlier approach was using a "serial number").  Debian is still 
using epochs in some places even though they've long provided facilities 
in apt to make them obsolete.  The distro I can positively say doesn't 
use any epoch numbers is openSUSE:

https://en.opensuse.org/openSUSE:Package_naming_guidelines

The idea of the epoch is to provide a total ordering among all possible 
version numbers, which still doesn't work if the ordering gets changed 
retroactivekly.  But a total ordering is not necessary to do in practise 
since you never keep all versions available in the install repo, so an 
ordering among the available versions is all that matters.


-- 
Achim.

(on the road :-)

Re: [[PATCH setup] 0/3] Prepare for colons in version numbers

[Brian Inglis]

On 2017-10-31 12:15, Achim Gratz wrote:
> Am 31.10.2017 um 12:21 schrieb Corinna Vinschen:
>> Not sure what distros you're referring to.  Of the 58467 packages
>> in Fedora 26, 7822 are using epochs.
> 
> I'm expecting as much since it was rpm that introduced the epoch IIRC (I think
> an earlier approach was using a "serial number").  Debian is still using epochs
> in some places even though they've long provided facilities in apt to make them
> obsolete.  The distro I can positively say doesn't use any epoch numbers is
> openSUSE:
> 
> https://en.opensuse.org/openSUSE:Package_naming_guidelines

OpenSUSE mandates package version rules and provides special characters to
mitigate any problems with upstream package version numbering, making the
OpenSUSE package version independent of the upstream version unless it conforms:

https://en.opensuse.org/openSUSE:Package_naming_guidelines#Handling_special_version_strings

> The idea of the epoch is to provide a total ordering among all possible version
> numbers, which still doesn't work if the ordering gets changed retroactivekly. 
> But a total ordering is not necessary to do in practise since you never keep all
> versions available in the install repo, so an ordering among the available
> versions is all that matters.

Another approach would be to add a packaging server release timestamp e.g.
strftime %s metadata which provides ordering independent of versions.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada