RFC: setup package in Base

RFC: setup package in Base

[Yaakov Selkowitz]

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

In order to speed up the adoption of the latest setup.exe, would it make
sense to ship it as a package?  Here is an initial draft of what this
might look like:

https://github.com/cygwinports/setup/blob/master/setup.cygport

Note that the executable itself is version/release-numbered so that we
never have to deal with replacing a running executable (setup itself).

Also, as an alternative to a simple symlink, what about a wrapper script
(such as the attached) that would allow more "yum-like" commands like
"cygsetup update" or "cygsetup install foo bar"?

-- 
Yaakov


[-- Attachment #2: cygsetup.in --]
[-- Type: text/plain, Size: 3629 bytes --]

#!/bin/bash

set -e;
set -x;

# Command Line Options:
# -D --download                     Download from internet
# -L --local-install                Install from local directory
# -s --site                         Download site
# -O --only-site                    Ignore all sites except for -s
# -R --root                         Root installation directory
# -x --remove-packages              Specify packages to uninstall
# -c --remove-categories            Specify categories to uninstall
# -P --packages                     Specify packages to install
# -C --categories                   Specify entire categories to install
# -p --proxy                        HTTP/FTP proxy (host:port)
# -a --arch                         architecture to install (x86_64 or x86)
# -q --quiet-mode                   Unattended setup mode
# -M --package-manager              Semi-attended chooser-only mode
# -B --no-admin                     Do not check for and enforce running as
#                                   Administrator
# -h --help                         print help
# -l --local-package-dir            Local package directory
# -r --no-replaceonreboot           Disable replacing in-use files on next
#                                   reboot.
# -X --no-verify                    Don't verify setup.ini signatures
# -n --no-shortcuts                 Disable creation of desktop and start menu
#                                   shortcuts
# -N --no-startmenu                 Disable creation of start menu shortcut
# -d --no-desktop                   Disable creation of desktop shortcut
# -K --pubkey                       URL of extra public key file (gpg format)
# -S --sexpr-pubkey                 Extra public key in s-expr format
# -u --untrusted-keys               Use untrusted keys from last-extrakeys
# -U --keep-untrusted-keys          Use untrusted keys and retain all
# -g --upgrade-also                 also upgrade installed packages
# -o --delete-orphans               remove orphaned packages
# -f --force-current                select the current version for all packages
# -Y --prune-install                prune the installation to only the requested packages
# -A --disable-buggy-antivirus      Disable known or suspected buggy anti virus
#                                   software packages during execution.

cygsetup ()
{
    local arch args exe;

    arch=$(arch)

    while (true) ; do
	case $1 in
	# accept some dnf flags
	-y|--assumeyes)
		args+=" --quiet-mode" ; shift ;;
	--downloadonly)
		args+=" --download" ; shift ;;
	--nogpgcheck)
		args+=" --no-verify" ; shift ;;
	--repofrompath)
		args+=" --site ${2#*,}"; shift 2 ;;
	# accept setup flags
	-K|-S)	args+=" $1 $2"; shift 2 ;;
	-*)	args+=" $1"; shift ;;
	esac
    done

    case "$args" in
    *--quiet-mode*) ;;
    *)	args+=" --package-manager" ;;
    esac

    case $1 in
    install)
	args+=" --packages "; shift;
	packages="$@" ; args+="${packages// /,}" ;;
    groupinstall)
	args+=" --categories "; shift;
	packages="$@" ; args+="${packages// /,}" ;;
    remove|erase)
	args+=" --remove-packages "; shift;
	packages="$@" ; args+="${packages// /,}" ;;
    groupremove)
	args+=" --remove-categories "; shift;
	packages="$@" ; args+="${packages// /,}" ;;
    update)
	args+=" --upgrade-also"; shift ;;
    distro-sync)
	args+=" --force-current --delete-orphans"; shift ;;
    '') ;;
    *)
	echo "ERROR: unknown argument: $1" >&2 ; exit 1 ;;
    esac

    cygstart -- /bin/setup-@VER@.exe \
	--arch ${arch/i6/x} \
	--no-shortcuts \
	--root $(cygpath -w /) \
	--local-package-dir $(cygpath -w /var/cache/setup) \
	$args
}

cygsetup "$@"

Re: RFC: setup package in Base

[Ken Brown]

On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
> In order to speed up the adoption of the latest setup.exe, would it make
> sense to ship it as a package?  Here is an initial draft of what this
> might look like:
> 
> https://github.com/cygwinports/setup/blob/master/setup.cygport
> 
> Note that the executable itself is version/release-numbered so that we
> never have to deal with replacing a running executable (setup itself).

I like the idea.  One thing to think about is how to deal with the 
situation in which a buggy version of setup fails to update itself. 
Maybe we should modify the existing warning that's issued when a newer 
version of setup is available.  It could say that setup should update 
itself, but it could also give a link to a script that does this 
manually in case something goes wrong.

> Also, as an alternative to a simple symlink, what about a wrapper script
> (such as the attached) that would allow more "yum-like" commands like
> "cygsetup update" or "cygsetup install foo bar"?

I like this too.  There seems to be no downside, since the wrapper 
accepts all existing setup flags.

Ken

Re: RFC: setup package in Base

[Jon Turney]

On 11/04/2018 00:14, Ken Brown wrote:
> On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
>> In order to speed up the adoption of the latest setup.exe, would it make
>> sense to ship it as a package?  Here is an initial draft of what this
>> might look like:
>>
>> https://github.com/cygwinports/setup/blob/master/setup.cygport

I'm not sure upx packing setup here is a good idea, since it interferes 
with debuggability, and we will be compressing the package archive anyhow.

>> Note that the executable itself is version/release-numbered so that we
>> never have to deal with replacing a running executable (setup itself).

True.

Not sure that when the setup package is upgraded, setup will be able to 
remove itself, though.

(Old setup-${VERSION}-${RELEASE}.exe lingering may be a price worth 
paying, though)

> I like the idea.  One thing to think about is how to deal with the 
> situation in which a buggy version of setup fails to update itself. 
> Maybe we should modify the existing warning that's issued when a newer 
> version of setup is available.  It could say that setup should update 
> itself, but it could also give a link to a script that does this 
> manually in case something goes wrong.

The instruction that setup currently emits telling you to update setup 
won't make a lot of sense if setup is then going to update itself

Also, I guess ideally setup should update itself first, rather than at 
the same time as all other packages...

>> Also, as an alternative to a simple symlink, what about a wrapper script
>> (such as the attached) that would allow more "yum-like" commands like
>> "cygsetup update" or "cygsetup install foo bar"?
> 
> I like this too.  There seems to be no downside, since the wrapper 
> accepts all existing setup flags.

Re: RFC: setup package in Base

[Brian Inglis]

On 2018-04-11 10:56, Jon Turney wrote:
> On 11/04/2018 00:14, Ken Brown wrote:
>> On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
>>> In order to speed up the adoption of the latest setup.exe, would it make
>>> sense to ship it as a package?  Here is an initial draft of what this
>>> might look like:
>>>
>>> https://github.com/cygwinports/setup/blob/master/setup.cygport
> 
> True.
> 
> Not sure that when the setup package is upgraded, setup will be able to remove
> itself, though.
> 
> (Old setup-${VERSION}-${RELEASE}.exe lingering may be a price worth paying, though)
> 
>> I like the idea.  One thing to think about is how to deal with the situation
>> in which a buggy version of setup fails to update itself. Maybe we should
>> modify the existing warning that's issued when a newer version of setup is
>> available.  It could say that setup should update itself, but it could also
>> give a link to a script that does this manually in case something goes wrong.
> 
> The instruction that setup currently emits telling you to update setup won't
> make a lot of sense if setup is then going to update itself
> 
> Also, I guess ideally setup should update itself first, rather than at the same
> time as all other packages...

Update check could be quick if a temp redirect is set up on the server from the
canonical name for backward compatibility, and HEAD If-Modified-Since request
used a la wget -N, curl -z, before the elevated child is spawned.

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

Re: RFC: setup package in Base

[Achim Gratz]

Jon Turney writes:
> Also, I guess ideally setup should update itself first, rather than at
> the same time as all other packages...

Please keep an option to not do this and especially not try to access
anything over the network.  Setup still needs to be able to work from a
local archive only.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: RFC: setup package in Base

[Ken Brown]

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

On 4/11/2018 12:56 PM, Jon Turney wrote:
> On 11/04/2018 00:14, Ken Brown wrote:
>> On 4/10/2018 2:12 PM, Yaakov Selkowitz wrote:
>>> In order to speed up the adoption of the latest setup.exe, would it make
>>> sense to ship it as a package?  Here is an initial draft of what this
>>> might look like:
>>>
>>> https://github.com/cygwinports/setup/blob/master/setup.cygport
> 
> I'm not sure upx packing setup here is a good idea, since it interferes 
> with debuggability, and we will be compressing the package archive anyhow.
> 
>>> Note that the executable itself is version/release-numbered so that we
>>> never have to deal with replacing a running executable (setup itself).
> 
> True.
> 
> Not sure that when the setup package is upgraded, setup will be able to 
> remove itself, though.

I've just tested this, and in fact the running setup doesn't remove itself.

> (Old setup-${VERSION}-${RELEASE}.exe lingering may be a price worth 
> paying, though)

I think some users would find it confusing and annoying.  Maybe the 
setup package could provide a perpetual postinstall script that tries to 
remove old versions.

>> I like the idea.  One thing to think about is how to deal with the 
>> situation in which a buggy version of setup fails to update itself. 
>> Maybe we should modify the existing warning that's issued when a newer 
>> version of setup is available.  It could say that setup should update 
>> itself, but it could also give a link to a script that does this 
>> manually in case something goes wrong.
> 
> The instruction that setup currently emits telling you to update setup 
> won't make a lot of sense if setup is then going to update itself

I'm attaching a patch to setup that adds a new option, 
--no-version-warning, to suppress that warning.  (The patch also 
slightly rewords the warning.)  Two further patches, to setup.cygport 
and cygsetup.in, make the setup shortcuts and the cygsetup script use 
that option.

One other comment about the shortcuts and script: I don't think they 
should use the --local-package-dir option.  By the time the shortcuts or 
script are first run, the user will have already run setup at least once 
and will have provided a local package directory.  It could only cause 
confusion for us to change this.

> Also, I guess ideally setup should update itself first, rather than at 
> the same time as all other packages...

This would be a nice feature (possibly with an option to disable it, as 
Achim requested).  But unless it can be done easily, I think we should 
go ahead with the setup package and save this for the future.

Ken


[-- Attachment #2: 0001-Add-no-version-warning-option.patch --]
[-- Type: text/plain, Size: 1902 bytes --]

From 50575f3bef73e37e86662b4f1a975dca074effaf Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 5 Jul 2018 11:22:20 -0400
Subject: [PATCH] Add --no-version-warning option

This suppresses the warning that a newer version of setup is
available.  It is intended to be used by shortcuts and scripts that
run /usr/bin/setup-<version>.exe (from the 'setup' package).

Also reword the warning so that it mentions
/usr/bin/setup-<version>.exe.
---
 IniDBBuilderPackage.cc | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/IniDBBuilderPackage.cc b/IniDBBuilderPackage.cc
index 48a5d4a..1cdae08 100644
--- a/IniDBBuilderPackage.cc
+++ b/IniDBBuilderPackage.cc
@@ -29,8 +29,12 @@
 #include "PackageSpecification.h"
 #include <algorithm>
 
+#include "getopt++/BoolOption.h"
+
 using namespace std;
 
+static BoolOption NoVersionWarningOption (false, '\0', "no-version-warning", "Suppress warning that a newer version of setup is available");
+
 IniDBBuilderPackage::IniDBBuilderPackage (IniParseFeedback const &aFeedback) :
 currentSpec (0), _feedback (aFeedback){}
 
@@ -51,13 +55,15 @@ IniDBBuilderPackage::buildVersion (const std::string& aVersion)
   version = aVersion;
   if (version.size())
     {
-      if (version_compare(setup_version, version) < 0)
+      if (version_compare(setup_version, version) < 0
+	  && !NoVersionWarningOption)
 	{
 	  char old_vers[256];
 	  snprintf (old_vers, sizeof old_vers,
 	    "The current ini file is from a newer version of setup-%s.exe. "
 	    "If you have any trouble installing, please download a fresh "
-	    "version from https://cygwin.com/setup-%s.exe",
+	    "version from https://cygwin.com/setup-%s.exe, or use "
+	    "/usr/bin/setup-<version>.exe, provided by the 'setup' package.",
 	    is_64bit ? "x86_64" : "x86",
 	    is_64bit ? "x86_64" : "x86");
 	  _feedback.warning(old_vers);
-- 
2.17.0


[-- Attachment #3: 0001-Use-no-version-warning-in-cygsetup-script.patch --]
[-- Type: text/plain, Size: 675 bytes --]

From 5a1b1c62ae1ae82604b0e64a510cbe1c9c8f1d79 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 5 Jul 2018 12:47:21 -0400
Subject: [PATCH] Use --no-version-warning in cygsetup script

---
 cygsetup.in | 1 +
 1 file changed, 1 insertion(+)
 mode change 100755 => 100644 cygsetup.in

diff --git a/cygsetup.in b/cygsetup.in
old mode 100755
new mode 100644
index c4b0adc..6bf271a
--- a/cygsetup.in
+++ b/cygsetup.in
@@ -92,6 +92,7 @@ cygsetup ()
     cygstart -- /bin/setup-@VER@.exe \
 	--arch ${arch/i6/x} \
 	--no-shortcuts \
+	--no-version-warning \
 	--root $(cygpath -w /) \
 	--local-package-dir $(cygpath -w /var/cache/setup) \
 	$args
-- 
2.17.0


[-- Attachment #4: 0001-Use-no-version-warning-in-shortcuts.patch --]
[-- Type: text/plain, Size: 1231 bytes --]

From a1529ce5f71e7b9cafcb82f13fb6c6fcdb1a0d68 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 5 Jul 2018 12:39:37 -0400
Subject: [PATCH] Use --no-version-warning in shortcuts

---
 setup.cygport | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/setup.cygport b/setup.cygport
index c0f312b..ad2790b 100644
--- a/setup.cygport
+++ b/setup.cygport
@@ -35,11 +35,11 @@ src_install() {
 /usr/bin/mkdir -p "\$(/usr/bin/cygpath \$CYGWINFORALL -P)/Cygwin"
 /usr/bin/mkshortcut \$CYGWINFORALL -P -w /var/log \
   -n "Cygwin/Cygwin${ARCH_x86_64+64} Setup" \
-  -a "--local-package-dir \$(cygpath -w /var/cache/setup)" \
+  -a "--no-version-warning --local-package-dir \$(cygpath -w /var/cache/setup)" \
   /usr/bin/setup-${VERSION}-${RELEASE}.exe
 /usr/bin/mkshortcut \$CYGWINFORALL -P -w /var/log \
   -n "Cygwin/Update Cygwin${ARCH_x86_64+64}" \
-  -a "--no-shortcuts --package-manager --upgrade-also --local-package-dir \$(cygpath -w /var/cache/setup)" \
+  -a "--no-shortcuts --package-manager --upgrade-also --no-version-warning --local-package-dir \$(cygpath -w /var/cache/setup)" \
   /usr/bin/setup-${VERSION}-${RELEASE}.exe
 _EOF
 	cat > ${D}/etc/preremove/setup.sh <<_EOF
-- 
2.17.0

Re: RFC: setup package in Base

[Achim Gratz]

Ken Brown writes:
>> Not sure that when the setup package is upgraded, setup will be able
>> to remove itself, though.
>
> I've just tested this, and in fact the running setup doesn't remove itself.

It would have scared me if it did.

>> (Old setup-${VERSION}-${RELEASE}.exe lingering may be a price worth
>> paying, though)
>
> I think some users would find it confusing and annoying.  Maybe the
> setup package could provide a perpetual postinstall script that tries
> to remove old versions.

Hmm.  That doesn't sound appealing, just that I don't really know what
else to suggest.

Well, except getting rid of setup altogether in a way (I think I've
vented that idea before to howls of protest): Do the whole package
selection, download and local caching stuff from inside Cygwin and then
shut itself down and kick off a Win32 installer that makes it all
happen.  That installer could come with the base Cygwin since it's never
going to change and doesn't need to know know much beyond where to find
the Cygwin root and how to unpack from the cache dir.  Postinstall could
be forked out to dash.  When modularized in the right way the updater
could even be run as a service and/or around a regularly scheduled
reboot.

I sort of have something like that running @work, I do all the package
selection, downloading and local repo setup with a perl script (so no
GUI) and only use setup to do the actual installation (selection of the
installation content via injected package groups).


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: RFC: setup package in Base

[cyg Simple]

On 7/5/2018 3:26 PM, Achim Gratz wrote:
> Ken Brown writes:
>>> Not sure that when the setup package is upgraded, setup will be able
>>> to remove itself, though.
>>
>> I've just tested this, and in fact the running setup doesn't remove itself.
> 
> It would have scared me if it did.
> 

A scheme I've used for this is to rename the executable files and then
mark them for delete on close.  This moves the file name out of the way
for a new file of the same name.

-- 
cyg Simple

Re: RFC: setup package in Base

[Jon Turney]

On 05/07/2018 19:34, Ken Brown wrote:
>> The instruction that setup currently emits telling you to update setup 
>> won't make a lot of sense if setup is then going to update itself
> 
> I'm attaching a patch to setup that adds a new option, 
> --no-version-warning, to suppress that warning.  (The patch also 
> slightly rewords the warning.)  Two further patches, to setup.cygport 
> and cygsetup.in, make the setup shortcuts and the cygsetup script use 
> that option.

Thanks for the patch.

The version is checked (again), at ini.cc:404

I've never understood why we have this twice.

(I think the idea might be that first we are checking the setup version 
as a proxy for the setup.ini format version, to warn if there might be 
problems parsing it.  The second time we are checking the setup version 
to see if an upgrade of setup is possible)

Surely the advice should be to update the 'setup' package, rather than 
to use it?

Re: RFC: setup package in Base

[Jon Turney]

On 06/07/2018 14:51, Jon Turney wrote:
> Thanks for the patch.
> 
> The version is checked (again), at ini.cc:404
> 
> I've never understood why we have this twice.
> 
> (I think the idea might be that first we are checking the setup version 
> as a proxy for the setup.ini format version, to warn if there might be 
> problems parsing it.  The second time we are checking the setup version 
> to see if an upgrade of setup is possible)

Ah, so now we have setup-minimum-version, checking setup-version: in the 
ini parser should probably be removed (or disabled when 
setup-minimum-version: is present?)

Re: RFC: setup package in Base

[Jon Turney]

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

On 06/07/2018 15:05, Jon Turney wrote:
> On 06/07/2018 14:51, Jon Turney wrote:
>> Thanks for the patch.
>>
>> The version is checked (again), at ini.cc:404
>>
>> I've never understood why we have this twice.
>>
>> (I think the idea might be that first we are checking the setup 
>> version as a proxy for the setup.ini format version, to warn if there 
>> might be problems parsing it.  The second time we are checking the 
>> setup version to see if an upgrade of setup is possible)
> 
> Ah, so now we have setup-minimum-version, checking setup-version: in the 
> ini parser should probably be removed (or disabled when 
> setup-minimum-version: is present?)

Like so:


[-- Attachment #2: 0001-Add-no-version-check-option.patch --]
[-- Type: text/plain, Size: 1366 bytes --]

From 0955c7b05bdb50ae180e9ab5f9bfb3c8489a0242 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Thu, 5 Jul 2018 11:22:20 -0400
Subject: [PATCH setup 1/2] Add --no-version-check option

This suppresses the warning that a newer version of setup is available.

This is intended to be used by shortcuts and scripts that run setup in a
'setup' package.

This would also suppress any future auto-update feature.
---
 ini.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ini.cc b/ini.cc
index 7afeba2..78684a7 100644
--- a/ini.cc
+++ b/ini.cc
@@ -62,6 +62,7 @@ IniList setup_ext_list (setup_exts,
 			setup_exts + (sizeof(setup_exts) / sizeof(*setup_exts)));
 
 static BoolOption NoVerifyOption (false, 'X', "no-verify", "Don't verify setup.ini signatures");
+static BoolOption NoVersionCheckOption (false, '\0', "no-version-check", "Suppress checking if a newer version of setup is available");
 
 extern int yyparse ();
 
@@ -401,7 +402,8 @@ do_ini_thread (HINSTANCE h, HWND owner)
        setup_version);
   if (ini_setup_version.size ())
     {
-      if (version_compare (setup_version, ini_setup_version) < 0)
+      if ((version_compare (setup_version, ini_setup_version) < 0)
+          && !NoVersionCheckOption)
 	note (owner, IDS_OLD_SETUP_VERSION, setup_version,
 	      ini_setup_version.c_str ());
     }
-- 
2.17.0


[-- Attachment #3: 0002-If-setup-minium-version-was-checked-don-t-check-setu.patch --]
[-- Type: text/plain, Size: 2174 bytes --]

From 7e82fb4f179155da810101133ab7189f93ed52d4 Mon Sep 17 00:00:00 2001
From: Jon Turney <jon.turney@dronecode.org.uk>
Date: Fri, 6 Jul 2018 17:45:42 +0100
Subject: [PATCH setup 2/2] If setup-minium-version: was checked, don't check
 setup-version:

Don't check setup-version: to warn about potential setup.ini parsing
problems if a setup-minimum-version: is specified.
---
 IniDBBuilderPackage.cc | 11 ++++++++++-
 IniDBBuilderPackage.h  |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/IniDBBuilderPackage.cc b/IniDBBuilderPackage.cc
index 48a5d4a..87a0058 100644
--- a/IniDBBuilderPackage.cc
+++ b/IniDBBuilderPackage.cc
@@ -32,7 +32,7 @@
 using namespace std;
 
 IniDBBuilderPackage::IniDBBuilderPackage (IniParseFeedback const &aFeedback) :
-currentSpec (0), _feedback (aFeedback){}
+  currentSpec (0), _feedback (aFeedback), minimum_version_checked(FALSE) {}
 
 IniDBBuilderPackage::~IniDBBuilderPackage()
 {
@@ -48,6 +48,14 @@ IniDBBuilderPackage::buildTimestamp (const std::string& time)
 void
 IniDBBuilderPackage::buildVersion (const std::string& aVersion)
 {
+  /* We shouldn't need to warn about potential setup.ini parse problems if we
+     exceed the version in setup-minimum-version: (we will still advise about a
+     possible setup upgrade in do_ini_thread()).  If we don't exceed
+     setup-minimum-version:, we've already encountered a fatal error, so no need
+     to warn as well. */
+  if (minimum_version_checked)
+    return;
+
   version = aVersion;
   if (version.size())
     {
@@ -68,6 +76,7 @@ IniDBBuilderPackage::buildVersion (const std::string& aVersion)
 const std::string
 IniDBBuilderPackage::buildMinimumVersion (const std::string& minimum)
 {
+  minimum_version_checked = TRUE;
   if (version_compare(setup_version, minimum) < 0)
     {
       char min_vers[256];
diff --git a/IniDBBuilderPackage.h b/IniDBBuilderPackage.h
index 79a864e..e5d3662 100644
--- a/IniDBBuilderPackage.h
+++ b/IniDBBuilderPackage.h
@@ -91,6 +91,7 @@ private:
   std::set <std::string> replace_versions;
 
   IniParseFeedback const &_feedback;
+  bool minimum_version_checked;
 };
 
 #endif /* SETUP_INIDBBUILDERPACKAGE_H */
-- 
2.17.0

Re: RFC: setup package in Base

[Ken Brown]

On 7/7/2018 8:40 AM, Jon Turney wrote:
> On 06/07/2018 15:05, Jon Turney wrote:
>> On 06/07/2018 14:51, Jon Turney wrote:
>>> Thanks for the patch.
>>>
>>> The version is checked (again), at ini.cc:404
>>>
>>> I've never understood why we have this twice.
>>>
>>> (I think the idea might be that first we are checking the setup 
>>> version as a proxy for the setup.ini format version, to warn if there 
>>> might be problems parsing it.  The second time we are checking the 
>>> setup version to see if an upgrade of setup is possible)
>>
>> Ah, so now we have setup-minimum-version, checking setup-version: in 
>> the ini parser should probably be removed (or disabled when 
>> setup-minimum-version: is present?)
> 
> Like so:

Yes, this is better than my attempt.  I hadn't noticed that 
setup-version: was checked again in ini.cc.

Ken