* [[PATCH setup] 3/3] Remove the ScanFindVisitor class
2017-10-27 18:47 [[PATCH setup] 0/3] Prepare for colons in version numbers Ken Brown
@ 2017-10-27 18:47 ` Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 1/3] Remove the function filemanip.cc:base Ken Brown
` (3 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: Ken Brown @ 2017-10-27 18:47 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [[PATCH setup] 1/3] Remove the function filemanip.cc:base
2017-10-27 18:47 [[PATCH setup] 0/3] Prepare for colons in version numbers Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 3/3] Remove the ScanFindVisitor class Ken Brown
@ 2017-10-27 18:47 ` Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 2/3] Bump the installed.db version to 4 Ken Brown
` (2 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: Ken Brown @ 2017-10-27 18:47 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [[PATCH setup] 2/3] Bump the installed.db version to 4
2017-10-27 18:47 [[PATCH setup] 0/3] Prepare for colons in version numbers Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 3/3] Remove the ScanFindVisitor class Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 1/3] Remove the function filemanip.cc:base Ken Brown
@ 2017-10-27 18:47 ` Ken Brown
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
2017-10-30 15:55 ` Jon Turney
4 siblings, 0 replies; 15+ messages in thread
From: Ken Brown @ 2017-10-27 18:47 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 18:47 [[PATCH setup] 0/3] Prepare for colons in version numbers Ken Brown
` (2 preceding siblings ...)
2017-10-27 18:47 ` [[PATCH setup] 2/3] Bump the installed.db version to 4 Ken Brown
@ 2017-10-27 19:27 ` Achim Gratz
2017-10-27 19:33 ` Ken Brown
` (3 more replies)
2017-10-30 15:55 ` Jon Turney
4 siblings, 4 replies; 15+ messages in thread
From: Achim Gratz @ 2017-10-27 19:27 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
@ 2017-10-27 19:33 ` Ken Brown
2017-10-27 19:48 ` Brian Inglis
` (2 subsequent siblings)
3 siblings, 0 replies; 15+ messages in thread
From: Ken Brown @ 2017-10-27 19:33 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
2017-10-27 19:33 ` Ken Brown
@ 2017-10-27 19:48 ` Brian Inglis
2017-10-27 20:31 ` Yaakov Selkowitz
2017-10-30 15:58 ` Jon Turney
3 siblings, 0 replies; 15+ messages in thread
From: Brian Inglis @ 2017-10-27 19:48 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
2017-10-27 19:33 ` Ken Brown
2017-10-27 19:48 ` Brian Inglis
@ 2017-10-27 20:31 ` Yaakov Selkowitz
2017-10-30 15:58 ` Jon Turney
3 siblings, 0 replies; 15+ messages in thread
From: Yaakov Selkowitz @ 2017-10-27 20:31 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
` (2 preceding siblings ...)
2017-10-27 20:31 ` Yaakov Selkowitz
@ 2017-10-30 15:58 ` Jon Turney
2017-10-31 10:06 ` Achim Gratz
3 siblings, 1 reply; 15+ messages in thread
From: Jon Turney @ 2017-10-30 15:58 UTC (permalink / raw)
To: cygwin-apps
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...
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-30 15:58 ` Jon Turney
@ 2017-10-31 10:06 ` Achim Gratz
2017-10-31 11:21 ` Corinna Vinschen
0 siblings, 1 reply; 15+ messages in thread
From: Achim Gratz @ 2017-10-31 10:06 UTC (permalink / raw)
To: cygwin-apps
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 :-)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-31 10:06 ` Achim Gratz
@ 2017-10-31 11:21 ` Corinna Vinschen
2017-10-31 16:22 ` Brian Inglis
2017-10-31 18:16 ` Achim Gratz
0 siblings, 2 replies; 15+ messages in thread
From: Corinna Vinschen @ 2017-10-31 11:21 UTC (permalink / raw)
To: cygwin-apps
[-- 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 --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-31 11:21 ` Corinna Vinschen
@ 2017-10-31 16:22 ` Brian Inglis
2017-10-31 18:16 ` Achim Gratz
1 sibling, 0 replies; 15+ messages in thread
From: Brian Inglis @ 2017-10-31 16:22 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-31 11:21 ` Corinna Vinschen
2017-10-31 16:22 ` Brian Inglis
@ 2017-10-31 18:16 ` Achim Gratz
2017-10-31 18:32 ` Brian Inglis
1 sibling, 1 reply; 15+ messages in thread
From: Achim Gratz @ 2017-10-31 18:16 UTC (permalink / raw)
To: cygwin-apps
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 :-)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-31 18:16 ` Achim Gratz
@ 2017-10-31 18:32 ` Brian Inglis
0 siblings, 0 replies; 15+ messages in thread
From: Brian Inglis @ 2017-10-31 18:32 UTC (permalink / raw)
To: cygwin-apps
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
2017-10-27 18:47 [[PATCH setup] 0/3] Prepare for colons in version numbers Ken Brown
` (3 preceding siblings ...)
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
@ 2017-10-30 15:55 ` Jon Turney
4 siblings, 0 replies; 15+ messages in thread
From: Jon Turney @ 2017-10-30 15:55 UTC (permalink / raw)
To: cygwin-apps
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...
^ permalink raw reply [flat|nested] 15+ messages in thread