Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Adam D. Barratt-29
[this doesn't appear to have reached the tech-ctte list yet, so I'm
replying from the BTS archive]

On 2017-03-09 9:41, Pirate Praveen wrote:
> Package: tech-ctte
[...]
> I request CTTE to declare this bug as not RC.

That's not something that the Technical Committee has a remit to do.

The determination as to whether a bug is release-critical is delegated
to the Release Team. So far as I can tell you haven't approached them to
discuss this, so you can't be asking the TC to override a decision by a
delegate either, as there hasn't explicitly been one.

Regards,

Adam

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Ian Jackson-2
Adam D. Barratt writes ("Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing"):
> On 2017-03-09 9:41, Pirate Praveen wrote:
> > I request CTTE to declare this bug as not RC.
>
> That's not something that the Technical Committee has a remit to do.
>
> The determination as to whether a bug is release-critical is delegated
> to the Release Team. So far as I can tell you haven't approached them to
> discuss this, so you can't be asking the TC to override a decision by a
> delegate either, as there hasn't explicitly been one.

To be fair to Pirate, Andreas Beckmann suggested #856606 that if
Pirate disagreed with Andreas, Pirate should go to the TC.

I don't think any of the Release Team have been asked yet.

Sadly, there isn't a "reportbug release.debian.org" category for
"please determine RCness of #NNNN".  So I am just emailing
[hidden email] on this mail.


To debian-release:

The question is whether #856606 is RC.

I think you will find the best summary of the arguments in this
message:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606#37

Ian.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Andreas Beckmann-4
On 2017-03-09 18:00, Ian Jackson wrote:
> To be fair to Pirate, Andreas Beckmann suggested #856606 that if
> Pirate disagreed with Andreas, Pirate should go to the TC.

The disagreement between Pirate and me is not about the RC-ness of
#856606, but more about the general requirement of working upgrade paths.

This is my understanding of Pirate's point:

  "Package P hasn't been part of any stable release so far, therefore
   upgrades from earlier package versions don't have to be supported.
   So not having a working upgrade path from version 1.2-3 in testing
   to version 1.2-5 unstable is not a bug."

I didn't find anything in the policy about upgrade requirements ...
but I think there is a general agreement that direct upgrades must work
(and only skipping over stable releases is not supported).


Andreas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Philip Hands
Andreas Beckmann <[hidden email]> writes:

> On 2017-03-09 18:00, Ian Jackson wrote:
>> To be fair to Pirate, Andreas Beckmann suggested #856606 that if
>> Pirate disagreed with Andreas, Pirate should go to the TC.
>
> The disagreement between Pirate and me is not about the RC-ness of
> #856606, but more about the general requirement of working upgrade
> paths.

Looking at the bug, I see that the issue involves this bit of code:

  export $(cat /etc/gitlab/gitlab-debian.conf)

(and other variations thereof) used in the maintainer scripts, and
suggested in the README as something for the user to run.

It strikes me as rather fragile, and likely to misbehave in surprising
ways -- e.g. if one comments out a line in the file with '# ' then the
setting will still get set.

Is it not possible to patch the code of the package to contain the
default paths internally, so that it is not essential to populate the
environment before running things?

Failing that, how about setting the defaults and exporting them in a
wrapper script, which could also source the config file (in the more
normal way) before then invoking rake (or whatever), and then using that
in place of running rake etc. directly?

Either of these should mean that one could have an empty/missing config
file under /etc, or include comments in the config file, and still have
things work properly.

I suspect that much of the tangled code for handling the config files
would drop away if you did this, which ought to also ensure that this
bug would disappear.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Tollef Fog Heen
In reply to this post by Andreas Beckmann-4
]] Andreas Beckmann

> On 2017-03-09 18:00, Ian Jackson wrote:
> > To be fair to Pirate, Andreas Beckmann suggested #856606 that if
> > Pirate disagreed with Andreas, Pirate should go to the TC.
>
> The disagreement between Pirate and me is not about the RC-ness of
> #856606, but more about the general requirement of working upgrade paths.
>
> This is my understanding of Pirate's point:
>
>   "Package P hasn't been part of any stable release so far, therefore
>    upgrades from earlier package versions don't have to be supported.
>    So not having a working upgrade path from version 1.2-3 in testing
>    to version 1.2-5 unstable is not a bug."

>From reading through the bug log, that is my understanding of his point
as well.

The upgrade is from a previous version of gitlab that has been in
stretch for a little under a month (it went into testing on
2017-02-18).  I think it's completely clear that failure to support
upgrades (even between short-lived versions that only hit unstable) is a
bug.  For versions that hit testing, even more so.

In the typical cases where we don't support upgrades between major
versions (think apache 1 → 2), we typically renamed the packages
involved.  That seems overly heavy-handed in this case where the upgrade
path can just be fixed (see mail from Phil Hands for some suggestions),
but it points to what the bar is.

The guidelines are more lax for experimental where people have been
known to not make it possible to move to testing/unstable versions of
the package without reinstalling/reconfiguring it.  I think this is, and
should be, discouraged but allowed.  Experimental exists for a reason:
to be able to conduct experiments, and sometimes you need to burn the
experiment to the ground afterwards.

> I didn't find anything in the policy about upgrade requirements ...
> but I think there is a general agreement that direct upgrades must work
> (and only skipping over stable releases is not supported).

There are a lot of requirements for packages that are not written in
policy.  There's no requirement in Policy as written that changelogs
must be in English, for instance.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Philip Hands
Tollef Fog Heen <[hidden email]> writes:

> ]] Andreas Beckmann
>
>> On 2017-03-09 18:00, Ian Jackson wrote:
>> > To be fair to Pirate, Andreas Beckmann suggested #856606 that if
>> > Pirate disagreed with Andreas, Pirate should go to the TC.
>>
>> The disagreement between Pirate and me is not about the RC-ness of
>> #856606, but more about the general requirement of working upgrade paths.
>>
>> This is my understanding of Pirate's point:
>>
>>   "Package P hasn't been part of any stable release so far, therefore
>>    upgrades from earlier package versions don't have to be supported.
>>    So not having a working upgrade path from version 1.2-3 in testing
>>    to version 1.2-5 unstable is not a bug."
>
>>From reading through the bug log, that is my understanding of his point
> as well.
>
> The upgrade is from a previous version of gitlab that has been in
> stretch for a little under a month (it went into testing on
> 2017-02-18).  I think it's completely clear that failure to support
> upgrades (even between short-lived versions that only hit unstable) is a
> bug.  For versions that hit testing, even more so.
The problem with upgrades is due to the change of location of the
defaults which were being read from under /usr/share/doc/

Not using /usr/share/doc/ in this way is a clear improvement.

The upgradeability bug is related to the fact that the config file
includes the location of the default (*.example) files, and that has
changed, but being a conffile it can persist with the old setting into
the running of the new version's scripts.

The underlying problem is that settings that are only really useful to
the first invocation of the postinst (the paths to the *.example files)
are making their way into the package's configuration under /etc.

One ought to be able to sort out the specific upgrade bug in an updated
unstable package, but that does nothing to fix the package in stretch.

I'd expect to see more bugs related to this code.

I'm not sure if that counts as RC, but it seems clear that plastering
over the cracks with patches to the unstable package does nothing to
address the underlying problems of cruft in /etc and sloppy scripting.

Unfortunately, now we're frozen, fixing the stretch package might be a
problem, although if we agree that this is RC, then I guess we can still
fix it :-)

I'm happy to come up with a patch if that helps.[1]

Cheers, Phil.

[1] Moving the files out of /usr/share/doc/ and hard-wiring the new
paths into the postinst would do the trick (unless there is some reason
to be able to configure their location, which I cannot really imagine).

I presume those settings are used nowhere else, in which case they
should be renamed in the script, in order to avoid the export $(cat ...)
code overwriting the new settings.

Rewriting the export $(cat ...) code at the same time would be nice, but
the release managers would need to decide if they think that the
existing code is nasty enough to allow a bigger patch.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

gregor herrmann-3
On Fri, 10 Mar 2017 12:00:22 +0100, Philip Hands wrote:

> The problem with upgrades is due to the change of location of the
> defaults which were being read from under /usr/share/doc/
>
> Not using /usr/share/doc/ in this way is a clear improvement.

Indeed, if only because it would fix a policy vioalation :)

12.3. Additional documentation
[..]
     Packages must not require the existence of any files in
     `/usr/share/doc/' in order to function [1].
[..]    
[1]  The system administrator should be able to delete files in
     `/usr/share/doc/' without causing any programs to break.


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Diana Krall: Black Crow

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Emilio Pozuelo Monfort-4
In reply to this post by Andreas Beckmann-4
On 09/03/17 19:21, Andreas Beckmann wrote:

> On 2017-03-09 18:00, Ian Jackson wrote:
>> To be fair to Pirate, Andreas Beckmann suggested #856606 that if
>> Pirate disagreed with Andreas, Pirate should go to the TC.
>
> The disagreement between Pirate and me is not about the RC-ness of
> #856606, but more about the general requirement of working upgrade paths.
>
> This is my understanding of Pirate's point:
>
>   "Package P hasn't been part of any stable release so far, therefore
>    upgrades from earlier package versions don't have to be supported.
>    So not having a working upgrade path from version 1.2-3 in testing
>    to version 1.2-5 unstable is not a bug."
>
> I didn't find anything in the policy about upgrade requirements ...
> but I think there is a general agreement that direct upgrades must work
> (and only skipping over stable releases is not supported).

Yes.

Cheers,
Emilio

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Julien Cristau-6
In reply to this post by Philip Hands
On Fri, Mar 10, 2017 at 12:00:22 +0100, Philip Hands wrote:

> One ought to be able to sort out the specific upgrade bug in an updated
> unstable package, but that does nothing to fix the package in stretch.
>
> I'd expect to see more bugs related to this code.
>
> I'm not sure if that counts as RC, but it seems clear that plastering
> over the cracks with patches to the unstable package does nothing to
> address the underlying problems of cruft in /etc and sloppy scripting.
>
> Unfortunately, now we're frozen, fixing the stretch package might be a
> problem, although if we agree that this is RC, then I guess we can still
> fix it :-)
>
We can also remove the package from stretch, which should give the
maintainer more time to figure out a reasonable path forward for their
maintainer scripts and upgrade issues.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing

Andreas Beckmann-4
In reply to this post by Philip Hands
(dropping debian-release@ since this is about technical details in the
package)

On 2017-03-09 23:13, Philip Hands wrote:

> Looking at the bug, I see that the issue involves this bit of code:
>
>   export $(cat /etc/gitlab/gitlab-debian.conf)
>
> (and other variations thereof) used in the maintainer scripts, and
> suggested in the README as something for the user to run.
>
> It strikes me as rather fragile, and likely to misbehave in surprising
> ways -- e.g. if one comments out a line in the file with '# ' then the
> setting will still get set.

$ cat test-cat-export.sh
# This is a comment.
variable=value
quoted="foo 42 baz"
$ export $(cat test-cat-export.sh)
bash: export: `#': not a valid identifier
bash: export: `comment.': not a valid identifier
bash: export: `42': not a valid identifier
bash: export: `baz"': not a valid identifier
$ echo $?
1

Oh yeah, adding a comment or quoting a string containing spaces will
break the maintainer script.
You can't even add a comment

  # Don't use comments or "quote strings" in this file.


Andreas

Loading...