Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> Right.  Whichever init system we pick, I do expect the next step to be to
> drop the requirement to maintain sysvinit backwards-compatibility;

While I'm not sure from your mail whether you meant to suggest otherwise, I do
think that whatever we decide for jessie, we should continue the requirement of
sysvinit compatibility for at least one release after we ship with some more
modern init system.

Also, since all alternative init implementations under consideration do
support sysv-style init scripts, I think that whatever init system we
(well, you, the TC) end up choosing, the requirement in policy should be
that a package should ship either some init configuration for the
default init system, or a sysv-style init script. In fact, I think we
should continue to encourage the latter, in cases where it does make
sense (e.g., when a given daemon doesn't have any init system specific
features that could be enabled), since that will help our non-Linux
ports without significantly impacting performance of the new init
system.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131028172214.ga11...@master.debian.org

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.

With some work, sure.

> This is a much better outcome
> across our distribution as a whole than to require developers to continue
> maintaining init scripts just for our non-Linux ports.

I did not say "require", I said "encourage". I agree that it's
unreasonable to expect developers to maintain init scripts that they
themselves do not use in addition to init configuration for whatever
init system we end up with; and I do agree that it should be fair game
for people to drop the init script from their package.

However, there are some advantages to be had in continue to ship init
scripts (while I can see no downsides, apart from the fact that they
need to be written), and in that light it can make sense for us to
encourage people to continue shipping init scripts.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/



signature.asc
Description: OpenPGP digital signature

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez  writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
> 
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
> 
>> And here is the reply from Gentoo developer Patrick Lauer:
> 
>> http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
> 
> This, sadly, was not particularly useful or interesting.

I disagree. His point isn't argued very well (seems more like a rant
than a discussion), but it's there.

> As near as I can
> tell, the core content was that he doesn't think cgroup management is
> particularly difficult (fine, but I don't think that was the point; the
> point, instead, was that it's important to have a single arbitrator, which
> if true poses specific technical challenges) and he believes that the
> components to systemd would be easy to implement as separate daemons if
> they were properly documented.
> 
> I'm one of those people who thinks that nearly everything in Linux is
> horribly underdocumented, so I'm not going to argue with that point, but
> it's not a very useful statement from a practical viewpoint.  systemd
> offers specific pieces of integrated functionality.  By and large, no one
> seems to question that the operations enabled by that functionality are
> useful (although there is some debate over how useful).  GNOME is not
> depending on systemd out of some nefarious plot.  It's depending on
> systemd because GNOME wants to use those pieces of functionality systemd
> provides.
> 
> Therefore, I think it's important for arguments against using systemd to
> somehow engage directly with the questions about functionality.  Either
> there needs to be an argument that the functionality is not important and
> can be done without (which raises questions about how one would build
> GNOME in such an environment), or there needs to be some sort of plan for
> how equivalent functionality to systemd will be provided.

>From the above link:

"The only thing stopping me from reimplementing that functionality is
that I have no idea what it's supposed to *do* ... and I don't enjoy
reading through all of systemd to find out."

(about logind)

While I agree with your point, it's pretty difficult to reimplement the
"interesting" parts of systemd in other implementations of pid1 if
whoever wrote the "interesting" parts does not document it, does not say
what it's supposed to do, does not want to accept patches for things
they're not interested in, and is by and large uninterested in anyone
who prefers to use something else than whatever their kool-aid is.

I'll grant that maybe logind provides interesting functionality which
other projects might want to depend on, and that there's nothing wrong
with that. The problem, however, is that the functionality is not
defined: if I want to provide an alternative pid1 implementation, then
the specifications are clear, and I should Just Do It (not that I'm
going to muddle the waters even more by doing so, but you understand the
point). If I want to provide an alternative implementation of logind,
however, then the only spec out there is the logind code, which might
change one day to the next just because the logind developer feels like it.

This wouldn't be much of a problem if I could just take logind (and
udev, and dbus, and more things) out of the systemd source tree and use
it without systemd, should I want to. But you can't; the problem is that
the upstream of all these projects is by and large uninterested in doing
so, and also does not seem to support other people who are, and at least
the Debian maintainers of systemd have gone on record as saying that
they won't guarantee this would remain possible (if the systemd
developers would be willing to do so, then I suppose that could
ameliorate some concerns).

The "obvious" solution would be that the world changes to systemd
because what, essentially, amounts to a level of sabotage by the systemd
developers of things that aren't systemd. If systemd is in fact the best
choice "out there", of which I'm not convinced at this point in time,
then I wouldn't mind that (much). But I'd like us to do so for the right
technical reasons, not just because it means we make our lives easier in
not having to fight with a stubborn upstream all the time. We could,
after all, fork, like we have done on other occasions of stubborn upstreams.

Given all of the above, I would even argue that perhaps Debian should
*not* adopt systemd as init system, out of principle; if we were to do
so, then almost all the major distributions would be using systemd (with
the sole exception of Ubuntu; I expect redhat to switch to systemd for
their next EL version), which could go a long way to making it part of
what it means to be running "Linux". At that point, any competing
innovative implementations would simpl

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Wouter Verhelst]

Op 31-10-13 02:50, Theodore Ts'o schreef:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of exposing
>> some of those degrees of freedom to every init script author, but if you
>> have some more specific examples of policy that you wanted to change but
>> couldn't, I'd be interested in examples.
> 
> It's not necessarily the init script author who might want the degrees
> of freedom, but the local system administrator.
> 
> The most basic is the idea that whether you can control (via shell
> scrpit fragments) whether or not a service should start at all, and
> what options or environments should be enabled by pasing some file.
> The fact that we can put that sort of thing in configuration files
> such as /etc/default/*, for example.

This, in my opinion, is one of the worst abominations we currently have
in Debian.

Whether an init script should run at boot time has no relation
whatsoever to whether it should run when the system administrator calls
it manually. Yet, with "ENABLE=" variables in /etc/default, this is
related, because the initscript will say "I'm disabled, go edit this
file if you want to start me", even if you just want to start a daemon
just this once manually, for testing.

AIUI, both upstart and systemd have configuration options where you can
tell the system that this particular service should not start at boot;
that will then, however, not affect the result when one manually tries
to start the service.

I'm not sure that's a very good argument ;-)

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52721ab2.7030...@debian.org

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote:
> Testing and unstable have completely separate and independent
> archives, you can point an image builder to one OR the other, in
> isolation, and it will produce a fully complete and runnable and
> bootable OS tree. The fact that they might have some or even all
> content in common at particular points in time is orthogonal and
> unrelated to what the purpose of os-release is.

I suspect this is the crux of your problem. Perhaps it might be useful
to explain what "the purpose of os-release" is, exactly? I suspect that
most people here see testing as more similar to unstable than not, and
in order for us to find common ground, understanding *why* this matters
for os-release might be useful.

For what it's worth, I do have one argument in favour of your position.
In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
currently running". That code starts off with "parse os-release", and
then falls back to a horrible horrible perl script that parses
apt-cache policy output if os-release looks like testing or unstable,
because the autopkgtest needs to test the version that we're running,
not "always unstable", and this is just a pain. If os-release were to
distinguish "unstable" from "testing", then I would be able to get rid
of that perl script (and good riddance)

But I don't think that's the right answer, and it would be good if you
could clarify this.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sun, Aug 04, 2024 at 01:00:38PM +0200, Paul Gevers wrote:
> Hi Wouter,
> 
> On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst  wrote:
> > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> > currently running". That code starts off with "parse os-release", and
> > then falls back to a horrible horrible perl script that parses
> > apt-cache policy output if os-release looks like testing or unstable,
> > because the autopkgtest needs to test the version that we're running,
> > not "always unstable", and this is just a pain. If os-release were to
> > distinguish "unstable" from "testing", then I would be able to get rid
> > of that perl script (and good riddance)
> 
> If I read correctly then what you describe here you fell in the trap that
> helmut mentioned earlier (but maybe you realized and implemented it
> correctly). You should run in the same environment that is prepared as your
> testbed.

This is off-topic for the ctte discussion, but: this part of the
autopkgtest is about testing the initrd scripts in the nbd package,
which you can only do by booting a VM image. This requires us to
generate something that can be booted over an NBD connection, which we
do by way of "debvm-create" (whose implementation uses debootstrap).
We then export this generated image through the nbd server that is
installed in the testbed, and then use "debvm-run" to boot the image
over NBD.

This is very much a corner case, but *in order* for me to test what the
testbed provides, I need to know what it is, exactly, that it is
providing, and that does not appear to be in the autopkgtest API beyond
the "use what is installed", and that just doesn't work when I need to
generate a bootable image.

Perhaps if autopkgtest were to pass debootstrap arguments to be used for
creation of a chroot if the test requires it, then I could stop using my
script, but in the mean time...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > both be erroneously identified as trixie
> >
> > Isn't there the third option of adhering to the os-release specification
> > without making testing and unstable distinguishable? I did not see this
> > ranked in your preference. Do you see it as even worse than the status
> > quo?
> 
> There isn't such option. Adhering to the specification means
> identifying them separately, given they can be built separately, ran
> separately, managed separately. So the option you are referring to is
> for the opposite: _not_ adhering to the specification, and yes, that
> is an option.

For completion's sake:

There is a third option of updating the os-release specification to
declare that there is no relevant difference between distributions such
as Debian's testing and unstable (for some definition of a class of
distributions that would encompass the two) and that it is not necessary
for os-release files to distinguish between them.

I make no statement as to whether this is a good idea or not, but it is
definitely a possibility.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst  wrote:
> >
> > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne  wrote:
> > > > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > > > both be erroneously identified as trixie
> > > >
> > > > Isn't there the third option of adhering to the os-release specification
> > > > without making testing and unstable distinguishable? I did not see this
> > > > ranked in your preference. Do you see it as even worse than the status
> > > > quo?
> > >
> > > There isn't such option. Adhering to the specification means
> > > identifying them separately, given they can be built separately, ran
> > > separately, managed separately. So the option you are referring to is
> > > for the opposite: _not_ adhering to the specification, and yes, that
> > > is an option.
> >
> > For completion's sake:
> >
> > There is a third option of updating the os-release specification to
> > declare that there is no relevant difference between distributions such
> > as Debian's testing and unstable (for some definition of a class of
> > distributions that would encompass the two) and that it is not necessary
> > for os-release files to distinguish between them.
> >
> > I make no statement as to whether this is a good idea or not, but it is
> > definitely a possibility.
> 
> That would make it contradictory with itself and everything else that
> uses it, so it's not a change that would be acceptable.

Why not?

You seem to hold the opinion in this discussion that the os-release
specification is perfect and that Debian's implementation of it is
wrong and should be corrected and there is no discussion.

I'm not saying that's not true, but it does make it more difficult to
understand the reasoning.

I happen to be involved with NBD upstream, and as such have worked on
the specification of the NBD protocol. I *could* declare in that
specification that any system that implements the NBD protocol MUST (in
an RFC 2119 sense) make sure that port 10809 (assigned by IANA to NBD)
can only ever be used for NBD, but that would be unreasonable and is not
going to fly, and any implementor of the NBD protocol would be well
within their rights to ignore that part of the specification, in
contradiction of the standard.

In a similar sense, I feel that it's not entirely unreasonable for a
distribution to declare that a part of the os-release specification is
making unreasonable demands of a distribution in certain situations, and
that to implement those parts of the specifications is too much effort
and therefore will not happen, in contradiction of the standard. Perhaps
this could be one of those situations.

You want to update the implementation in Debian to more closely match
the specification. I and others have asked you what the benefit of this
would be, but TTBOMK the answers you have given all essentially boiled
down to "because that is what the standard requires", and/or "because
people might want to know the difference between the two", without going
into detail or providing real-world examples as to why this would be the
case. I myself have even given a real-world example, but then it turned
out that this was not even a good idea and Helmut Grohne showed me a
better way to implement what I needed to do.

I would like to request that you give this a real hard thought, and try
to come up with a good description of some realistic scenarios where the
current state of affairs is problematic, how it is problematic, and how
the proposed change would resolve that. There are after all real costs
involved to the suggestions you have made; updating packages in the
Essential set is not trivial, and can have distribution-wide impacts on
far more packages than just the ones that are being changed. Going
through testing-proposed-updates, as you have proposed, requires manual
work from the release team, updates to the dak software to special-case
the os-release package, or both. And even the mere idea of having an
easily-distinguishable difference between testing and unstable could
cause packages to behave differently between testing and unstable, which
would invalidate the whole reason we even have that distinction between
testing and unstable in the first place. And while maintaining a package
that ships a five-line file (plus supporting scripts and a changelog) is
trivial, the ancillary work involved in making this happen, and the
resulting effects that could occur, is decidedly not trivial. So, in
order for the ctte to consider this[1], I think it is necessary

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst  wrote:
> > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > > That would make it contradictory with itself and everything else that
> > > uses it, so it's not a change that would be acceptable.
> >
> > Why not?
> 
> Because A is A, not B.
> 
> > You seem to hold the opinion in this discussion that the os-release
> > specification is perfect and that Debian's implementation of it is
> > wrong and should be corrected and there is no discussion.
> >
> > I'm not saying that's not true, but it does make it more difficult to
> > understand the reasoning.
> 
> Nobody said anything is perfect.

And yet:

[...]
> You cannot argue that the math book is wrong and Debian is right to
> say that 2+2=5.

The os-release specification is not a math book. It is an
English-language specification. Specifications like that are not math.

It is perfectly viable to accept that certain things are difficult to do
for one distribution, perhaps even too difficult to do, and that
therefore it is not worth doing. But in order to make that call, it is
necessary to know more.

> > You want to update the implementation in Debian to more closely match
> > the specification. I and others have asked you what the benefit of this
> > would be, but TTBOMK the answers you have given all essentially boiled
> > down to "because that is what the standard requires", and/or "because
> > people might want to know the difference between the two", without going
> > into detail or providing real-world examples as to why this would be the
> > case. I myself have even given a real-world example, but then it turned
> > out that this was not even a good idea and Helmut Grohne showed me a
> > better way to implement what I needed to do.
> 
> Please see (plenty) of other mails. I know there's a lot of noise and
> it takes time to sift through the walls of texts, but that's why I do
> not want to add even more.

Please do not mistake my disagreement for misunderstanding.

I have read every mail in this thread. I have perhaps skipped over some
parts of some emails which were going off on a tangent, but I have
definitely read every one of *your* words in this thread. I have also
opened the links to various other sites and bug reports that you have
posted. In short, I *have* done my homework, thank you very much.

> I added multiple examples,

I have seen vague handwavy statements of "people might want to do this".
I have seen examples where you explain how a set of commands does not
result in the os-release file having the "correct" contents.

What I have not seen is *why this matters*, despite asking multiple
times. "Because that is what the os-release spec says" is a circular
non-answer.

The question is: 

  what is, exactly, the problem that the os-release specification is
  supposed to solve? And how does unstable and testing being
  undistinguishable from each other not solve that problem?

I have not seen an answer to that question, and it is, I think the
central question that we need to see answered. Because that would show
what the *benefit* of the os-release specification is, and that would
allow the ctte to do a proper cost-benefit analysis of the proposed
solutions.

While I don't think this is the case, it is of course not entirely
impossible that I have missed or overlooked the reply to the question I
state above, in which case I apologise and would kindly ask that you
point to it.

[...]
> > Given the what we know so far, in my opinion (for as much as that one
> > holds merit), Debian should declare that we implement the os-release
> > specification only from the time of the release of our distribution
> > suites, and that the data in the os-release file before that (i.e., in
> > our development suites) could be right or could be wrong but that we do
> > not warrant that it is either way.
> 
> That's not what happens right now though - the file is there, so it is
> implemented.

The file is there, but as you assert it does not implement the spec
correctly, it is not implemented correctly. So allow me to rephrase: at
this point we implement the os-release specification correctly only from
the time of release, not before, and without explanation as to why we
should, I don't think that should change.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1077764: Ruling request on os-release specification implementation

[Wouter Verhelst]

On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst  wrote:
> > The question is:
> >
> >   what is, exactly, the problem that the os-release specification is
> >   supposed to solve? And how does unstable and testing being
> >   undistinguishable from each other not solve that problem?
> >
> > I have not seen an answer to that question, and it is, I think the
> > central question that we need to see answered. Because that would show
> > what the *benefit* of the os-release specification is, and that would
> > allow the ctte to do a proper cost-benefit analysis of the proposed
> > solutions.
> >
> > While I don't think this is the case, it is of course not entirely
> > impossible that I have missed or overlooked the reply to the question I
> > state above, in which case I apologise and would kindly ask that you
> > point to it.
> 
> Yes, I'm afraid you did miss it, as it has been answered multiple
> times. Please re-read replies from myself, Gioele and Marc.

- Gioele's message is about reimplementing lsb_release in terms of
  os-release. As it wants to do largely the same thing as os-release, it
  stands to reason that it would have the same problems, but that does
  not actually answer the question as to what the problem is you're
  trying to solve. Surely the reason that os-release exists is not "so
  we have a way to implement the lsb_release script". In fact, if that
  were the only reason, then we could do away with os-release entirely,
  implement lsb_release for Debian in terms of parsing apt
  configuration, and we wouldn't even be having this discussion.
- Marc's answer is an example involving managing the life cycle, using
  ansible, of various hosts. While that is indeed a real-life example
  where something like os-release could be useful, it is not an answer
  to the question of what it is, exactly, that os-release is trying to
  do. You do not answer a question "what is the problem that X is trying
  to solve" by way of "here is one example of things that are easier",
  because it is always possible to give a counter-example of things that
  would decidedly *not* be easier -- such as managing quality in Debian
  in light of packages that change their behavior if they detect that
  they're on a different distribution.
- You gave multiple instances of "people want to do this" without going
  into detail as to why.

This question matters, because understanding the need is the first step
in understanding why the current situation is suboptimal.

>From my point of view, the need has always been the ability to identify,
with limited detail, what a particular installation contains. I say
"with limited detail", because it can never be complete by way of a
single file; there will always be more details that such a file format
cannot express. But this is sufficient for things like labelling other
installations on the same hardware in a boot menu, remembering what you
were trying to do with that image on the disk somewhere, or various
other cases where a hint as to what an image is could help.

It can never be more than a hint, however; there is always more detail
to be found. For instance, in the case of Debian stable, os-release does
not tell you when the installation was last updated, what the exact way
was in which the installation was created, or which set of third-party
sources was added to the system to install packages from.

I'm sure there are people who want to know this type of information
beyond what Debian is currently willing to provide, and of course they
are then required to add random hacks to their scripts to improve the
situation. Similarly, I'm sure there may also be people who would need
to know more than which suite a package was built from -- I regularly
check dpkg logs to figure out when last an installation was updated, for
instance -- and so if I want to do that automatically, then I will also
have to hack my code to improve upon that. There is really no difference
here.

The fact that Debian has two in-development suites is actually an
implementation detail of Debian, and to decide that *this* one
implementation detail of a particular installation is important enough
to be reflected in a file, but all these other implementation details of
what the image was built from are not, seems fairly arbitrary from my
point of view.

I'm sure it does not for you, but you have not explained why it is that
it is not arbitrary. Specifically, you have not explained why Debian
should *care*.

We provide an os-release file. It provides information about the
installation. The information may be wrong according to the spec, but
I don't think that's a spec that Debian has agreed in any form or shape
to implement.

I

Bug#741573: Two menu systems

[Wouter Verhelst]

On Mon, 22 Dec 2014 14:29:44 + Ian Jackson 
 wrote:
> The traditional Debian menu system (mostly done by Bill Alombert) has
> been providing menu entries for bc and dc and everything for years.
> That is what its users expect.  It is what users like Matthew Vernon
> want:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20
> 
> What you are suggesting above is that the Debian menu will simply be
> abolished.

This seems correct.

> No-one will be allowed[1] to provide a comprehensive menu in Debian.

This doesn't.

The trad menu system and the desktop menu system are both, in essence,
just a bunch of metadata. What's represented in that metadata is "how do
you start this particular bit of software". To that extent, they are the
same.

The actual *contents* of the trad menu system and the desktop menu
system is vastly different. I suspect that the opposition to losing the
trad menu system is not so much about the metadata *format* as it is
about the *contents* of those menu systems; about the actual menus that
result from interpreting the metadata.

But I don't see why that would need to be a problem, or indeed be part
of this question.

There is no reason why we wouldn't, theoretically, be able to build a
menu system that had a semantically similar (although perhaps differing
in minor details, such as "categories" etc) contents as does the trad
menu system, but using desktop metadata rather than trad metadata.

There is no reason why "moving to desktop files as supported menu
system" must imply "losing most or all of the contents that the trad
menu currently contains". It could, yes, and maybe it would make sense
if some of the more... "unusual" menu entries (such as those for "bash"
or "python") were removed from the menu system. However, that is a
wholly different question as to the question of which metadata format we
decide to go with, long-term.

I submit that the TC, for the purpose of answering this question before
it, should at first simply decide on a preferred metadata format. The
contents of the resulting menus is something they can then decide on as
a separate question (or ignore altogether if they decide it is not
appropriate for them to make that decision).

I will add that the debian menu is an all-or-nothing approach; TTBOMK it
is not possible to create an entry in the Debian menu saying something
along the lines of "this should not be shown by default" or "this should
not be shown by default in environment X". This might be one reason for
the choice of some of our DE maintainers to decide not to show the
Debian menu anymore.

The same is not true for the desktop metadata format.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141227161131.ga2...@grep.be

Bug#741573: #741573: Menu Policy and Consensus

[Wouter Verhelst]

Hi Sam,

[side note: while I joined the original discussion, I don't really have
a stake in the outcome, other than the desire to have a working menu]

On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote:
> Should Bill have recused?
> Your current process does not describe when policy editors should
> recuse.
> One thing we may learn here is that we need to be more clear about how
> we handle recusals.

I'm not sure if the lack of a policy on recusals is a good excuse for
the failure to do so. If Bill opposed the proposal (which certainly is
his right), he *should* have actively partaken in the discussion,
pointing out *why* he thought it a bad idea and asking for
clarifications, improvements, etc. Instead, he mostly ignored the
discussion while it was happening (not counting the occasional mails
pointing out what he believed to be inaccuracies), and only making fully
clear that he was going to oppose the proposal when he reverted the
commit that implemented what others thought to be consensus.

I don't think this is appropriate for anyone, regardless of whether
they're policy editors. If you have an objection to a technical change
in Debian, historically we've always required that people come up with
technical reasons for either supporting or objecting to, the change.
Bill did not do that, at least not to the level I would expect from
someone who opposes a proposed change that seems to be building
consensus.

Anyway.

While I applaud your attempts to get the original people around the
table again, I'm not sure that's either productive or the role of the
TC. Not productive, because I feel that the different parties have
pretty much reached set positions that they're extremely unlikely to
deviate from anymore; and not the role of the TC, because it is the
technical committee's role to take *technical* decisions, which this
approach would not necessarily lead to.

Instead, I would prefer if the technical committee would, after
reviewing the arguments pro and con, take a decision on *which menu
system* to move forward with, rather than trying to fix the original
discussion, for which I have little hope that it will be successful.

I do believe Charles' original mail was a request for the TC to do so.
If it isn't in your interpretation, please consider this an official
request in that manner.

Thanks,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Wouter Verhelst]

On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Debian" are quite common, even in front of a poster describing
> exactly that. With having separate official images for all blends,
> people would even be more confused. As an example, I would take the
> Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
> installation options -- people usually think that they have to
> re-install the system if they want to switch from one flavour to the
> other. Having similar experience with Debian would be bad for the
> reputation of the Blends, and for Debian in general.

I don't agree with this argument.

Yes, indeed, in Ubuntu people often don't know that they don't really
need a reinstall to go from Kubuntu to Xubuntu (or whatever), but is
that really a problem?

It's certainly *easier* for users to understand that if they want X, Y,
or Z, they just need to install from the X, Y, or Z image. We can
present them with a message at the end of the installation, or add some
documentation, or whatever, to the effect that switching from one "type"
of Debian to another doesn't require a reinstall; but even if that's
what people end up doing, so what? I don't see the problem -- and it
*would* make this problem go away, since you lose the need for the
tasksel menu entirely.

After all, Ubuntu isn't the only distribution anymore which ships
several images; these days, if you want to install Fedora, you have to
choose between a "workstation", "server", or "atomic"/"cloud" image. It
seems to work for them.

I don't buy that presenting users with a choice of image to download
"confuses" them, when it in fact *takes away* a very confusing menu from
the installer. I think it's going to be obvious to people that if you
download, say, a Debian Med image, you're going to have a different
experience than if you download a "plain vanilla" Debian image; and
that's *certainly* going to make things easier for Debian Med users,
too.

Just my 2¢.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Wouter Verhelst]

On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
> How about one or both of:
> 
>   bare-bones -- nothing selected
>   minimal-server -- ssh and nothing else
> 
> Is there any objective way of working out what other combinations would
> be popular, rather than just guessing?

Note that the whole point of tasksel was, originally, to show just that.
Things have simply gotten out of hand.

If you're going to update tasksel, it might be good to keep that in
mind...

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#877024: modemmanager should ask before messing with serial ports

[Wouter Verhelst]

On Wed, Sep 27, 2017 at 02:13:50PM -0700, Keith Packard wrote:
> Ian Jackson  writes:
> 
> (speaking as a Debian user, not as a TC member)
> 
> > I'm afraid don't really want to do the work of writing a better UI.
> > But I have provided a simple patch which at least makes the behaviour
> > safe.
> 
> Would it be sufficient to simply stop installing this largely-useless
> package at this point? In what environments do users typically have
> modems which work with AT-style commands?

ModemManager supports more than just those modems that work with AT
command sets; it supports the modern UMTS/3G/4G modems which don't even
support AT commands anymore, too.

> It would be far safer to not install this package than try to hack it up
> to keep it from breaking systems. Simply removing it from 'depends' on
> the handful of packages which currently list it would 'fix' this problem
> with a minimum of fuss.

Except that then for people who use NetworkManager, configuring their
mobile internet will stop functioning. While I agree with Ian that the
current behaviour of ModemManager is more than just highly annoying, it
cannot be said that ModemManager does not function as designed, nor that
it does not provide any useful functionality of which the loss would be
felt by those users who need it.

While dropping dependencies might make the issue somewhat less of a
problem, I don't think it's the right course of action.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#877024: modemmanager should ask before messing with serial ports

[Wouter Verhelst]

On Wed, Oct 18, 2017 at 09:18:37PM +0200, Aleksander Morgado wrote:
> On Tue, Oct 17, 2017 at 6:48 PM, Ian Jackson
> > I will do that upload: to DELAYED, picking some suitably cautious
> > version number, unless I hear to the contrary.  (And I'll wait at
> > least a week for a reply to this question.)
> >
> 
> How about waiting a bit until patches reviewed and tested upstream?

The whole point of experimental is "to test and review stuff". It's fine
if things break there; that's what it's for.

Having packages in experimental allows for more widespread testing. It
would seem that in this kind of situation, you would actually want
that...?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: TC nomination procedure v0

[Wouter Verhelst]

On Tue, Nov 28, 2017 at 09:40:45AM +0100, Didier 'OdyX' Raboud wrote:
> Question:
> 
>   - Does this private vote respect letter and/or intent of §6.3.4 "votes on
> appointments must be public"?

No. However, I think it is wrong for anyone to insist on that, and I
think the constitution should be updated to match the current (proper)
procedure.

It also doesn't require that the full details on the DPL vote be public,
for instance.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: TC nomination procedure v0

[Wouter Verhelst]

On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote:
> On Tue, 28 Nov 2017, Wouter Verhelst wrote:
> > On Tue, Nov 28, 2017 at 09:40:45AM +0100, Didier 'OdyX' Raboud wrote:
> > > Question:
> > > 
> > >   - Does this private vote respect letter and/or intent of §6.3.4 "votes 
> > > on
> > > appointments must be public"?
> > 
> > No. However, I think it is wrong for anyone to insist on that, and I
> > think the constitution should be updated to match the current (proper)
> > procedure.
> 
> I think it respects both the letter and intent.
> 
> My rationale is that the private "vote" isn't a vote on the appointment,
> it's a vote to figure out whether the future appointment vote will have
> consensus or not.

It's a vote that will have effect on the appointment of a person to the
TC. The constitution specifically wants appointment votes to be public.
Without wanting to comment on the letter, I think this is contrary to
the intent.

To be clear, I also think the consitution is wrong to require that such
votes are public. I think the TC should not have to make appointments in
public, for the very same reason that we also have secret ballots on DPL
votes. However, I think the correct course of action here is not to
ignore the constitution and explain that by some clever choice of words,
but rather to amend the constitution to make it be in line with that
rationale.

> If people feel strongly that the vote should be public,

Clearly, I don't feel that way.

Having said that though, I'm also not convinced that the current
completely private system is working very well.

Speaking as someone who's been a candidate for a number of past
appointments now, the process feels too much like a black box to me. You
submit your candidacy, you answer some questions, and then several
weeks or months later you learn that you haven't been chosen; and that's
it. I know from private conversations with certain TC members that the
reason for my non-selection was something along the lines of "there were
other people which seemed like stronger candidates", but none of that
was very clear, nor was it officially communicated.

I think a simple email to candidates after the appointment has been made
with some basic facts would be rather helpful. It could be something
along the lines of:

---
Thank you for your candidacy. However, you were not chosen this time
around.

There were about [5|10|15|20|30] candidates[1]. You were [eliminated
early on in the process|eliminated about halfway through the process|one
of the final contenders].

Apart from your own self-nomination, the TC received nominations from N
other people who thought you would make a good candidate, too.

In the end, person X was chosen mostly because [basic rationale].
---

This (intentionally) doesn't give too much detail, but it does allow
someone to evaluate whether their candidacy was a good idea, and whether
he/she should try again next time. I think doing so is necessary, indeed
even critical, if you want people to keep sending in their candidacy;
currently you don't get *any* feedback as a candidate, and that's not
very helpful, indeed even somewhat demotivating.

Additionally, similar feedback could be sent to people who sent in an
email to nominate others.

> one compromise is to allow nominees to the CTTE to choose to make
> their names public and force a public vote, with the default being the
> current private consensus process.

That could work too, but I'm personally not convinced that such a thing
is necessary, nor that it would be very beneficial to the process.

Thanks,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: TC nomination procedure v0

[Wouter Verhelst]

On Fri, Dec 01, 2017 at 11:25:01AM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> > On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote:
> > > My rationale is that the private "vote" isn't a vote on the appointment,
> > > it's a vote to figure out whether the future appointment vote will have
> > > consensus or not.
> 
> Given large sets of vetted nominees, it's can also be a "sorting" mechanism. 
> We could have more consensual candidates than seats to fill at a certain 
> point 
> in time, so using a condorcet-based process (yes, that's the Standard 
> Resolution Procedure) helps determining who has consensus _and_ is preferred 
> at that point in time. We don't want to have to downvote someone in public, 
> so 
> we make sure the public ballot has only the preferred candidate and FD.
> 
> This implies that: a) yes, the private vote is a preliminary vote on 
> appointment; b) the public vote is usually a mere formality.
> 
> (The public vote is only a formality given a relatively unanimous TC though; 
> and we could have a TC split about whom they'd want to get onboard. The 
> current process doesn't really address that hypothetical situation.)
> 
> > It's a vote that will have effect on the appointment of a person to the
> > TC. The constitution specifically wants appointment votes to be public.
> > Without wanting to comment on the letter, I think this is contrary to
> > the intent.
> > 
> > To be clear, I also think the consitution is wrong to require that such
> > votes are public. I think the TC should not have to make appointments in
> > public, for the very same reason that we also have secret ballots on DPL
> > votes. However, I think the correct course of action here is not to
> > ignore the constitution and explain that by some clever choice of words,
> > but rather to amend the constitution to make it be in line with that
> > rationale.
> 
> Would you be interested in drafting a GR for that, or is that too premature?

I think it's a bit premature at this point, yes, but something along the
following lines could work:

Index: constitution.wml
===
RCS file: /cvs/webwml/webwml/english/devel/constitution.wml,v
retrieving revision 1.28
diff -u -r1.28 constitution.wml
--- constitution.wml21 Aug 2016 15:28:11 -  1.28
+++ constitution.wml4 Dec 2017 08:07:16 -
@@ -582,8 +582,8 @@
 
 The Technical Committee may hold confidential discussions via
 private email or a private mailing list or other means to discuss
-appointments to the Committee.  However, votes on appointments must
-be public.
+appointments to the Committee in ways they see fit (including informal
+votes). However, final votes on appointments must be public.
   
 
   

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: TC nomination procedure v0

[Wouter Verhelst]

Hi Didier,

Thanks for caring.

On Fri, Feb 09, 2018 at 12:36:07PM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> > Having said that though, I'm also not convinced that the current
> > completely private system is working very well.
> > 
> > Speaking as someone who's been a candidate for a number of past
> > appointments now, the process feels too much like a black box to me.
> 
> The TC has had this feedback from multiple persons. There's clearly room for 
> improvement here.

Right.

> > You submit your candidacy, you answer some questions, and then several
> > weeks or months later you learn that you haven't been chosen; and that's
> > it. I know from private conversations with certain TC members that the
> > reason for my non-selection was something along the lines of "there were
> > other people which seemed like stronger candidates", but none of that
> > was very clear, nor was it officially communicated.
> 
> (Not speaking specifically about you) An aspect to keep in mind is that the 
> TC 
> is not _obligated_ to fill two of its seats; according to §6.2.{2,3,4}, the 
> TC 
> can freely navigate between 6 and 8 seats. As the TC nomination is a 
> coöptation (in that it picks project members it is willing to work together 
> with), there's a strong "personal fit" aspect that comes into play, and that 
> is both hard to explain, and to justify.

Yes, I understand where you're coming from, and I think it makes sense.

In fact, the above paragraph reminds me of an argument that was brought
up during the DPL election eight years ago, wherein a DD asked DPL
candidates (including myself, at the time) whether they thought the TC
should be allowed to self-appoint new members.

At the time I wrote a lengthy reply[1] that I won't repeat here, but
suffice to say that it shows I mostly agree with the above paragraph,
and that I still stand by most of what I wrote eight years ago.

[1] https://lists.debian.org/debian-vote/2010/03/msg00183.html

> In practice, the TC nomination is kinda like a hiring process. There are hard 
> facts, there are hard and soft skills, and there's personal fit. Not all of 
> it 
> is justifiable, or explainable, so I'm not in favour of asking the TC to 
> publish the ins and outs of its coöptation decisions, be it publicly or even 
> just towards the nominees.
[...]

That makes sense, and I fully support that, but a basic level of
feedback should be possible. I notice you've started announcing numbers.
I think that's a great start, but I would like to encourage you to not
stop there. Other options could be:

- If the number of candidates is large enough, give a vague description
  to the losing candidates how well they did in the secret election.
  Things like "You were one of the frontrunners", "You were somewhere in
  the middle of the pack" or "You were closer to the back than most
  people", for instance.
- If a general feeling of "this candidate may not have the right
  background for the TC" is common among current members, indicate so
  towards the candidate (without needing to go into too much detail).

etc. Also note that I think it's perfectly fine to reply to questions
for more detail with a "sorry, but we're not going to do that".

I also think it's perfectly fair to give less feedback if the number of
candidates is rather low (or, at least, to change the type of feedback
that you give in that case).

Anyway, thanks again, and feel free to completely ignore all that
feedback too if you think it makes no sense :-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab


signature.asc
Description: PGP signature

Re: Next Meeting: Wednesday, May 16th 19:00 UTC (today) - Currently no topics

[Wouter Verhelst]

On Wed, May 16, 2018 at 08:59:35PM +0200, Margarita Manterola wrote:
> As David mentioned in IRC and I mentioned in person to the people in
> Hamburg, it is a bit worrying to not have anything to discuss,

Why is it worrying?

The TC not having things to discuss means everyone in Debian is getting
along nicely. That's great! :-)

(well, okay, that's the theory)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Wouter Verhelst]

On Thu, Aug 02, 2018 at 09:46:28AM +0100, Simon McVittie wrote:
> mate-terminal and tilix, both terminals, have been adapted to Ubuntu
> having patched vte to stay with pcre instead of moving to pcre2.
> mate-terminal could easily use cpp; tilix is written in D, and I don't
> know whether that has a preprocessor.

It does not, but it does have a mechanism to have a somewhat limited
subset of D code be evaluated at compile time (which is actually far
more powerful than a preprocessor)

It also has an explicit mechanism for conditional compilation, which
would apply here; https://dlang.org/spec/version.html has the details on
how that works.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Wouter Verhelst]

On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> How should we handle architecture-specific patches properly inside 
> Debian?

Why should there ever be architecture-specific patches?

I get that there sometimes need to be vendor-specific patches, because
defaults may differ between distributions. But why on earth should
defaults differ between architectures? That just makes no sense. Things
like uintXX_t and htonl() should take away most architecture-specific
differences, and then all that remains are things like ensuring
alignment is done right. You don't need patches for that; you need
bugfree code for that.

I think, however, that "changing the defaults to make sure it matches
the one for this vendor" should be done as part of the build, if at all.
Doing it as part of unpacking the source is just wrong. When I run
"dpkg-source -x", I expect it to behave as would "unzip" or "tar x". To
have it act differently depending on the environment in which it is run?
That's just perverse.

[...]

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Wouter Verhelst]

On Mon, Aug 20, 2018 at 04:51:30PM +0300, Adrian Bunk wrote:
> On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote:
> > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> > > How should we handle architecture-specific patches properly inside 
> > > Debian?
> > 
> > Why should there ever be architecture-specific patches?
> > 
> > I get that there sometimes need to be vendor-specific patches, because
> > defaults may differ between distributions. But why on earth should
> > defaults differ between architectures? That just makes no sense. Things
> > like uintXX_t and htonl() should take away most architecture-specific
> > differences, and then all that remains are things like ensuring
> > alignment is done right. You don't need patches for that; you need
> > bugfree code for that.
> >...
> 
> Are we discussing bugfree code or are we discussing reality?
> 
> As an example, the non-release architectures of Debian are either
> brand-new (riscv64) or fringe with usually brittle upstream status
> in the toolchain (the other 13 non-release architectures).
> 
> Now look at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
> 
> "Keywords: deferred" means "This bug was deemed too risky to attempt to 
> fix during stabilization stages. Deferred to a development stage of a 
> subsequent release." AKA "Target Milestone: 9.0"
> 
> The bug seems to be rare enough on x86 to warrant that.
> 
> On ia64 this bug breaks most code that builds with -O3,
> Qt and Pyhon 3.7 were among the first FTBFS.
> 
> The fix will likely be in generic code in gcc.

Yes, but there's a huge difference here.

Compiling code for a given platform is not the same thing as running on
said platform. If the compiler runs correctly, then it doesn't matter
which platform it runs on; it's still the same compiler.

The architecture-specific issues that I was talking about, when they
occur in a compiler for a platform, can be patched perfectly safe, with
or without the agreement from upstream. If you see that a compiler
misbehaves when compiling *on* platform X but not when compiling *on*
platform Y (but in both cases compiling *for* platform Z), then you need
to fix the code on all platforms -- the ones where it is broken as well
as the ones where it is not broken -- and ship the fixed code. Hopefully
to upstream too, but definitely to Debian.

The architecture-specific code in a compiler that occurs when compiling
for a given platform needs to be built into *any* compiler which
produces code for that platform; so, not just in src:gcc-X, but also in
src:gcc-X-cross and src:gcc-X-cross-ports.

So even if we were to add code to dpkg-source to support
architecture-specific patches (which we don't currently and which I
think we definitely shouldn't), then this still wouldn't help the GCC
packages in Debian.

[...]
> And this can happen even on release architectures in a release.
> In src:gcc-6 the fix for #727621 [2], which is required for
> building LLVM on armel, is applied only on armel in stretch.

No; it is applied only on compilers that produce armel *output* in
stretch.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Wouter Verhelst]

On Sat, Sep 15, 2018 at 04:14:57PM -0300, David Bremner wrote:
> Tollef Fog Heen  writes:
> 
> >
> > The Committee recognises that there is a need for packages to behave
> > differently when built on different distributions, but this should be
> > done as part of the build process, using current and future practices
> > such as patches with conditional behaviour, patching of files during the
> > build, rather than at source unpacking time.
> 
> Does it need to be said that producing different source packages for
> different distributions is also perfectly acceptable?

I think that "different distributions" is by definition outside the authority
of the TC, and therefore it shouldn't even be mentioned in the resolution ;-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson 
> 
> Hi,
> 
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
> 
> I think this is the core question.  I largely agree with Ian here that
> having postinsts fail is not that big a deal if they can't make forward
> progress, but also we're being asked to advice on what happens when a
> maintainer script fails to restart a service.  I disagree with him on
> whether failure to start/restart a service should be considered a
> configuration failure.

I'm not sure why that position is even being considered valid.

> The API provided by a package being in the configured state is not
> whether the relevant daemon is running or not; that is runtime and can
> and will change many times while the package is in the configured state,
> so dpkg dependencies are not useful for expressing «this service must be
> running».

No. But it *is* a useful way to express "this service must be able to
run".

Additionally, if something fails to restart, then that is a serious
problem that I, as a system administrator, would like to know about.
Failure to configure a package signals that there is a serious problem
that I need to fix, so that informs me.

> (There's also the case where the service is running on a
> separate host, which is often the case for services such as databases
> and where the use of Depends is inappropriate.)
> 
> I think the general rule should be that the success/failure of the
> postinst script should signal whether the package considers itself ready
> to provide whatever API it exists to provide (disregarding the case of
> Essential packages here, since those are special).
> 
> This means that failure to start a daemon should generally not cause the
> postinst to fail.

I think it should.

If the daemon fails to restart, that means its configuration is
incomplete or incorrect, which means the package failed to configure
correctly. The failure to restart is just a symptom; the actual problem
is the broken configuration, which may have further effects beyond just
"the daemon won't restart". As such, in the general case, I think
failure to restart is something that should cause failure to configure.

There are really only two[1] reasons why a daemon could fail to restart:

- The maintainer made a mistake in the default configuration, and the
  user didn't make any changes so the old conffiles are being replaced
  by the new ones, or the package is being newly installed; now the
  daemon encounters a syntax error. This is a bug, plain and simple, and
  catching bugs earlier rather than later is a good idea, which will
  happen if the daemon restart failure causes a postinst failure.
- The maintainer made no mistake, but the upgrading user made some local
  changes, so the conffile system ensures that the syntactic differences
  in the configuration are not incorporated and the daemon fails to
  restart. As a system administrator, I would want to know when
  something like that happens sooner rather than later, so that I can
  fix it (also sooner rather than later). Failing to finish postinst
  correctly ensures that that does happen.

This is now being countered by "but some people use tools that don't
show failures to system administrators", from which the (wrong)
conclusion is drawn "so we shouldn't fail anymore". It would be awesome
if we lived in a world where we could avoid bugs in code and thus avoid
all possible failures, but alas, we don't. So, given that failures
*will* happen, even if we don't fail when daemons fail to restart, the
correct conclusion would be "so those tools should be fixed to do their
utter best to inform the system administrator when something failed".
When those tools do that, failure to restart a service is no longer a
problem for them, and we can continue to do the right thing.

[1] There is also the possibility of "the package ships with incomplete
configuration on purpose, because there are no sane defaults to use
and installing the package requires manual steps from the maintainer
before it can be made to work", but (a) our best practices recommend
against doing that if at all possible, and (b) in that case starting
the daemon shouldn't even be attempted from postinst, and so failure
to start can't be a consideration in the exit state of postinst.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

Hi Tollef,

On Fri, Sep 21, 2018 at 09:53:13PM +0200, Tollef Fog Heen wrote:
> ]] Wouter Verhelst 
> 
> > On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
> 
> [...]
> 
> > > The API provided by a package being in the configured state is not
> > > whether the relevant daemon is running or not; that is runtime and can
> > > and will change many times while the package is in the configured state,
> > > so dpkg dependencies are not useful for expressing «this service must be
> > > running».
> > 
> > No. But it *is* a useful way to express "this service must be able to
> > run".
> 
> That's not what «configured» means, though.

Disagree.

> «apt install foo ; rm /etc/foo.conf» and the package will be in a «running,
> but can't restart» state, but also configured in dpkg terms.

Well, sure, but that's true for any kind of configuration, and is not
specific to daemons: if you blow away a package's configuration, all
bets are off, so I fail to see your point.

The point is not "what happens after the install run has happened"; it
is about finding problems early rather than late.

> > Additionally, if something fails to restart, then that is a serious
> > problem that I, as a system administrator, would like to know about.
> > Failure to configure a package signals that there is a serious problem
> > that I need to fix, so that informs me.
> 
> I think monitoring should be implemented using monitoring tools, so if
> you actually care if a service is up, you should monitor it rather than
> relying on postinsts failing or succeeding.

First, the fact that there are tools to deal with this externally from
dpkg shouldn't mean that dpkg itself can't deal with it.

Second, if I manually upgrade something and postinst fails, I know
immediately that something is wrong; in contrast, if I upgrade something
but postinst does not fail, and then I have to rely on monitoring to
notify me, it may take a while before I notice something is wrong,
because monitoring tools often only tell me after a few minutes.

Third, the person who performs the upgrade is not necessarily the same
person as the one who notices something is wrong on the monitoring
system; the lack of immediate feedback that the upgrade broke things
will make debugging and fixing the problem more involved than it should
be.

I think "there are tools to do X" is a terrible argument for "postinst
shouldn't do X".

> Alternatively, you could just add «systemctl is-system-running» to a
> post-dpkg-invoke hook, it'll tell you if there are daemons that have
> failed.

The fact that I can do something to fix the fact that someone (you?)
broke reasonable expectations isn't an excuse for breaking those
reasonable expectations in the first place.

> [...]
> 
> > There are really only two[1] reasons why a daemon could fail to restart:
> > 
> > - The maintainer made a mistake in the default configuration, and the
> >   user didn't make any changes so the old conffiles are being replaced
> >   by the new ones, or the package is being newly installed; now the
> >   daemon encounters a syntax error. This is a bug, plain and simple, and
> >   catching bugs earlier rather than later is a good idea, which will
> >   happen if the daemon restart failure causes a postinst failure.
> > - The maintainer made no mistake, but the upgrading user made some local
> >   changes, so the conffile system ensures that the syntactic differences
> >   in the configuration are not incorporated and the daemon fails to
> >   restart. As a system administrator, I would want to know when
> >   something like that happens sooner rather than later, so that I can
> >   fix it (also sooner rather than later). Failing to finish postinst
> >   correctly ensures that that does happen.
> 
> In addition to this: Any number of runtime problems.  The disk might be
> full.  The service might try to look up a user whose name is in LDAP and
> the network is down and thus the user lookup fails.  Some hardware the
> service needs is not plugged in or doesn't work correctly.  Data files
> are corrupted.  Out of memory.  I'm sure you can come up with more. :-)

Well, yeah, and I like it if dpkg gives me an error when I try to
install something and, say, the disk is full.

> This then also ties into what the semantics of «daemon is started»
> should be: is it that the service has started, or that it is working?
> What should happen if you, on a host with no network connectivity (or
> just heavily firewalled), do «apt install ntp»?  Should it wait until
> the clock is synced (effectively forever in this case?  Should the
> postinst f

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

On Fri, Sep 21, 2018 at 10:07:31PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson 
> 
> > Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts 
> > fail to restart  a service"):
> 
> [...]
> 
> > > This means that failure to start a daemon should generally not cause the
> > > postinst to fail.
> > 
> > ... I disagree with that.  I think that in the usual case, if the
> > daemon is broken, and the package's purpose is to provide that daemon
> > service, then the package probably isn't providing its API.
> 
> I don't think dpkg relationships are a good fit for expressing those
> kinds of statements.  They are not about in-memory and process state
> management, they're about what's on disk.

The point here is that failure to restart the daemon is a *symptom* of
breakage of the *on-disk state*, so we're really arguing the same thing?

[...]
> > I disagree with this.
> > 
> > dpkg dependencies are not just about what sets of packages can be
> > coinstalled.  They also imply sequencing of package setup.  And since
> > starting daemons is part of package setup, dpkg dependencies imply a
> > sequencing of daemon startup.
> 
> If you include the word «attempted» there, I might agree.  policy-rc.d
> for instance enters the picture here.  Blacklisting in the init system
> does as well, probably others too.  The landscape is pretty crowded with
> actors.

Nobody is arguing that if the init system or policy-rc.d block service
starts, that then postinst should silently not start the daemon.

However, in the absense of such things, if postinst fails to restart the
daemon, it knows something is wrong. "something is wrong" should not
happen after package upgrade; if it did, we failed. "failed" means
postinst should not exist successfully.

> > That is actually necessary in the case where the startup of daemon B
> > can only successfully completed if daemon A is up,
> 
> That's the job of the init system's dependency resolution mechanisms,
> not dpkg's.  dpkg does not have information about what is running and so
> can't do this.  Ordering is also separate from dependencies, at least
> for some init systems.

Some init system dependency resolution mechanisms also only work
properly once all the packages involved have been configured, so that's
not a valid point.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

On Sat, Sep 22, 2018 at 09:50:11AM +0200, Wouter Verhelst wrote:
> Nobody is arguing that if the init system or policy-rc.d block service
> starts, that then postinst should silently not start the daemon.

That should read: 

Nobody is arguing that if the init system or policy-rc.d block service
starts, that then postinst should fail for not starting the daemon.

I'll go get some IV with caffeine now ;-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Wouter Verhelst]

On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
> That said, even there there are tradeoffs.
> As an example, Ubuntu tries to use unmodified Debian source packages
> where possible.  In some cases I think that the maintenance advantages
> of doing this and the slight but real political pressure it creates to
> push changes upstream to Debian may justify switching on dpkg-vendor.

I disagree with that, because it forgets why you're pushing things to
Debian.

The point of pushing things upstream is so that you as well as upstream
end up being the same, and the maintenance difference disappears. By
switching on dpkg-vendor, you're *not* the same; instead, you're hiding
your difference. This is not generally helpful; it simply moves the
maintenance burden from Ubuntu to Debian (where it simply does not
belong).

This is papering over a problem rather than fixing one.

> I think my point here is that there's a lot of complexity, and I'm not
> even convinced it would be desirable to recommend against using
> mechanisms like dpkg-vendor.

You can easily say "having downstream patches in Debian is generally a
bad idea for the same reasons that having Debian packaging in upstream
sources is generally a bad idea. However, if you must do it, XYZ is the
least terrible way to do so".

[...]
-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

Hi Simon,

Thanks for your summary.

On Sun, Oct 07, 2018 at 11:49:09AM +0100, Simon McVittie wrote:
> Attempting to summarize what was said on this topic in the thread so
> far, and at the last technical committee meeting:
> 
> It's perhaps important to note that we are not discussing ideal situations
> here: any time this conversation becomes relevant, something is already
> wrong. We're aiming to recommend the lesser evil, rather than something
> actually desirable.
> 
> One of the points of view here is Ian and Wouter's assertion that
> whenever a service fails to restart in a maintainer script, the most
> important thing is to make sure the sysadmin pays attention and fixes
> it before proceeding.
> 
> Julien Cristau made another point in support of "failure to restart
> implies failure to configure" on IRC, namely that the only straightforward
> thing for an automated upgrade to do is to look at the successful or
> failed exit status of the package manager (whether that means dpkg,
> apt, unattended-upgrades or whatever), and assume that exiting 0 means
> everything is fine and exiting nonzero means attention is required.

I think this is the core of the issue: it is incorrect to state that
when a service restart was successful, that then everything was fine.
There was a problem. We currently don't have a way to distinguish
between "there was a terrible problem and the sky is going to fall" and
"there was a problem but you might want ignore it", so technically the
only correct thing to do is to exit with a nonzero exit state,
signalling a problem. Put otherwise, I think that if the following
preconditions are true:

1. The service was running before the package upgrade
2. The package's postinst wants to restart the daemon
3. After the package upgrade, the service fails to start again

Then that means the package upgrade broke something, and the system
administrator should be informed of that fact. We currently have only
one *certain* avenue to inform the system administrator, and that is
through producing a nonzero exit state from apt. A debconf error or
message to stdout or stderr would work too in some cases, but the first
is not always shown and the second might scroll by too fast to be
noticeable, so it is not a certain way to tell the system administrator.
As such, exiting nonzero is the only avenue open to maintainers to do
the right thing.

Having said all that...

> At the opposite extreme, Marga's team manages thousands of desktops,
> and having to do *anything* manual to any significant number of them
> doesn't scale. We can think of inexperienced users' desktops as a bit
> like this scenario too, except that instead of having a professional
> sysadmin, they have to ask volunteers for help through channels like
> debian-user and #debian (and those volunteers' help doesn't really scale
> well either). It's also undesirable if the mechanism we use to escalate
> the failure to the user is one that itself makes it harder to diagnose or
> fix the problem, and in particular there's a concern that when packages
> fail to configure, that can make it harder to use apt to install the
> necessary tools to diagnose what has gone wrong; Stuart points out that in
> his experience of helping people in #debian, this is a practical problem.

It is true that there is a larger picture, and that in some
environments, breaking all future upgrades is way more problematic than
not restarting a service once. This is arguably a bug in apt though, and
it feels wrong to me to "fix" such an issue by introducing what is
essentially a workaround in multiple unrelated places; if then the
problem gets fixed properly, we would have to go around the whole system
to undo the workarounds again, which would be a sad state of affairs.

I can think of some alternatives that could be done and that would work
towards a resolution (rather than a workaround) for this problem:

- The policy-rc.d interface could be extended to allow it to signal a
  "restart, but do not fail on error" kind of policy. This would work
  for the "we have thousands of desktops and don't care about a service
  failing to restart" kind of enviromnent.
- Apt could be fixed so that when a package fails to configure, it would
  still be impossible to install and/or configure reverse-dependencies
  of the failing package, but not of packages that are unrelated. This
  would help the "users asking in our support channels can't install
  diagnostic tools to investigate" kind of situation.
- A new state could be created in dpkg to signal "configuration failed,
  but package will work for dependencies". When this is the case, apt
  should inform the user that configuration of some package failed and
  that they might want to investigate, but should not refuse to install
  and/or configure other packages, even reverse dependencies of the
  failing package. This feels right, but I can't come up with a good
  example of the kind of situation which this would fix; perh

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

[Wouter Verhelst]

On Tue, Oct 09, 2018 at 10:14:44AM -0400, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst  writes:
> 
> Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
> >> That said, even there there are tradeoffs.  As an example, Ubuntu
> >> tries to use unmodified Debian source packages where possible.
> >> In some cases I think that the maintenance advantages of doing
> >> this and the slight but real political pressure it creates to
> >> push changes upstream to Debian may justify switching on
> >> dpkg-vendor.
> 
> Wouter> I disagree with that, because it forgets why you're pushing
> Wouter> things to Debian.
> 
> Wouter> The point of pushing things upstream is so that you as well
> Wouter> as upstream end up being the same, and the maintenance
> Wouter> difference disappears. By switching on dpkg-vendor, you're
> Wouter> *not* the same; instead, you're hiding your difference. This
> Wouter> is not generally helpful; it simply moves the maintenance
> Wouter> burden from Ubuntu to Debian (where it simply does not
> Wouter> belong).
> 
> I think that we're agreed that evaluating the maintenance burden is
> exactly the right criteria.

Yes.

> Imagine a case where the same folks are maintaining a package for
> multiple distributions and where the difference is small but important.
> In such a case I think our users and the free software community might
> best be served by a single repository and switching on something a lot
> like dpkg-vendor.

Sure. For one thing though, it's incorrect to assume that the same group
of people will maintain a given package for all eternity, and that the
time when they *do* keep maintaining that package in Debian is the same
as for any number of derivative distributions.

This is all explained in
<https://wiki.debian.org/DebianMentorsFaq#What.27s_wrong_with_upstream_shipping_a_debian.2F_directory.3F>.
While that wiki page talks about the Debian-upstream relationship, many
of the same (kind of) arguments apply equally well to a
downstream-Debian relationship.

> Imagine a case where  it's a different set of people doing the work for
> Debian than the distribution that wants the change.  The Debian
> maintainers are not  in a good position to test the change and have no
> desire to do so.  There, switching on vendor seems like the wrong
> option.
> 
> We're a group of volunteers; we encourage cross-project collaboration
> and working together.  I  believe that the primary consideration should
> be what reduces the burden on those doing the work.  There are secondary
> considerations of course.

Sure.

Note, I'm not saying that we should outlaw the practice. There are
considerations for doing (or not doing) certain things; an experienced
Debian maintainer can certainly decide that in one particular case,
those considerations do not apply, and then it should be fine to ignore
the advice and do what is right.

But in the general case, I feel that downstream packaging changes belong
downstream, not in Debian; therefore it is best to recommend that, in
the general case, packages in Debian do not switch on dpkg-vendor.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> - The policy-rc.d interface could be extended to allow it to signal a
>   "restart, but do not fail on error" kind of policy. This would work
>   for the "we have thousands of desktops and don't care about a service
>   failing to restart" kind of enviromnent.

Wanting to investigate this a bit further, I find that, actually, such a
possibility already exists.

According to "man invoke-rc.d", policy-rc.d can exit with exit state 106
and provide a number of actions on stdout. These are then actions that
invoke-rc.d must try in order "until one of them succeeds". As such, a
policy-rc.d implementation written like so:

#!/bin/sh

if [ "$1" != ssh ]
then
exit 0
fi
echo "$2 stop"
exit 106

would result in the system attempting whatever init script action was
being asked for, followed by a "stop" action (except in the case of the
"ssh" service, which must not fail before we close a shell, ever). This
assumes that a "stop" action when the daemon fails to start will be
successful; I don't know whether all init scripts in Debian act that
way, but I do think that they should. If they do, then this will cause
mean that init scripts which fail will not cause general packaging
unhappiness.

With that background, IMHO the proper reply to this question before the
committee is that yes, postinst scripts should fail when an init script
fails, but we should also better document the policy-rc.d interface to
point out that the above is possible and can be done where it makes
sense. If long-time Debian Developers (not just me, but also the members
of the committee) do not know well how it works, then clearly it is
underdocumented!

(Having said that, I haven't tested any of this, so it is certainly
possible that the implementation does not match the documentation...)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

I must stop writing emails when tired...

On Tue, Oct 09, 2018 at 08:35:33PM +0200, Wouter Verhelst wrote:
> On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> > - The policy-rc.d interface could be extended to allow it to signal a
> >   "restart, but do not fail on error" kind of policy. This would work
> >   for the "we have thousands of desktops and don't care about a service
> >   failing to restart" kind of enviromnent.
> 
> Wanting to investigate this a bit further, I find that, actually, such a
> possibility already exists.
> 
> According to "man invoke-rc.d", policy-rc.d can exit with exit state 106
> and provide a number of actions on stdout. These are then actions that
> invoke-rc.d must try in order "until one of them succeeds". As such, a
> policy-rc.d implementation written like so:
> 
> #!/bin/sh
> 
> if [ "$1" != ssh ]

That is, of course, a logic inversion. Whoops.

> then
>   exit 0

For clarity, this means that whatever action was requested would be
allowed; and so if things fail they will cause the init script to fail,
too.

> fi
> echo "$2 stop"
> exit 106
-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#904558: What should happen when maintscripts fail to restart a service

[Wouter Verhelst]

Hi,

On Wed, Oct 17, 2018 at 09:47:57PM +0100, Simon McVittie wrote:
> However, it leaves the default as "fail hard", which I'm not convinced
> is the most appropriate thing for systems that lack an experienced
> sysadmin (which are the systems where defaults matter most, because an
> inexperienced user is the least able to make an informed decision about
> where they should deviate from defaults).

I think that's where we disagree, so allow me to focus on that.

I think everyone would agree that when a service fails to (re)start upon
package installation or upgrade, that there is a problem and that this
problem needs to be reported in whatever way is most appropriate (if
not, we have a bigger disagreement than I thought and we need to take a
step back ;-)

The question that remains is "how". Currently, Debian has four ways of
informing a system administrator of such failures:

- Log a message to stdout and/or stderr. This is liable to scroll by
  unnoticed, and therefore is not a reliable way to inform the system
  administrator. For that reason, I don't think it's a good idea.
- Log a message to syslog and/or the systemd journal. This will not
  scroll by, but relies on the system administrator to actively hunt for
  problems in system logs, which they probably won't do unless and until
  they notice that the daemon isn't running anymore (and by that time it
  may be too late).
- Produce a debconf error note. This is mildly better than the above
  two, since debconf error notes are shown at highest priority, and
  therefore will only be hidden if debconf is configured to be
  noninteractive; in that case, debconf will send an email to root. On
  systems without a configured MTA, this will not help; and for daemons
  where failure to restart is a catastrophic that needs to be resolved
  ASAP, such as sshd, this might not be desirable.
- Exit from postinst with nonzero exit state. This is unlikely to be
  missed by system administrators; however, it has several disadvantages
  that were pointed out by other people during this discussion.

I think it is perfectly fine to have the TC say that "failures to
restart a service must be reported, either by exiting nonzero, or by
another appropriate action", without going in detail what those other
actions could be.

> policy-rc.d also has some practical integration issues. It normally relies
> on putting an unpackaged file in /usr/sbin (unless you have installed
> policyrcd-script-zg2), and it's common for tools like debootstrap and
> debian-installer to create and delete policy-rc.d to suppress service
> startup while carrying out bootstrap operations. One Debian derivative
> that I'm involved in (SteamOS) is *meant* to have a policy-rc.d, but we
> recently discovered that it has always been deleted at the end of the
> debian-installer run, and so doesn't exist in practice.

I think that problem is not something that should be resolved by this
discussion.

I'll readily admit that I did not actually test any of the suggestions I
made wrt policy-rc.d. There are other issues with it too; I'm thinking
of filing a wishlist bug to have it replaced by something better.

On top of that, policy-rc.d has alwyas irked me as a bit of an awkward
interface; it is the only type of Debian-specific configuration that
does not go into /etc, but for which you need to write a script in
/usr/sbin. This is confusing, as shown by debian-installer removing it
unconditionally. In an ideal world, the policies currently implementable
through policy-rc.d should be configuration snippets in a run-parts
style directory. The "just drop a script somewhere" idea is a
poorly-defined interface which is inflexible and inappropriate for the
purpose of a distribution, but "policy-rc.d should be replaced by
something better" is not an appropriate response to the question "what
should happen when a service fails to restart in postinst".

Also related to this problem is what happens with postinst failing for
other reasons than "the daemon doesn't restart". While that is probably
the most likely reason for postinst failures today, it is by no means
the only one; so if you say "postinst failing because of daemon restart
failing" is something that should not ever happen, I think you should
then also make guidelines as to when, exactly, a postinst should be
allowed to fail (and muck up the whole system).

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
> 
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
> 
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Fri, Jul 26, 2019 at 06:45:35PM +0200, Guillem Jover wrote:
>   * This is a body composed of members that come and go, these might have
> wide experience in Debian in general (although not necessarily) or
> might had expertise in specific fields. The problem is that this body
> gets unbounded topic issues about anything. You cannot expect anyone
> w/ no prior experience to have "taste" or "intuition" about things
> they have not experienced/practiced for a long time. This is not,
> say, a java-ctte composed of Java experts.

To be fair, this used to not be the case, but then GR 2014-004 changed that.

Although I voted in favour of doing that, in hindsight I'm not sure it
was the right decision.

[...]
>   * Most decisions are not just technical decisions, in many/most cases
> the decisions have answers that are all correct, but it just depends
> on the weight of specific trade-offs. How those are weighted depends
> heavily on each individual. This also seems rather unfair, as it's
> taking the natural and expected biases of a small set of people in
> the project and forcing them into the entire project.

Honestly, if the answers are all correct and we've been going around in
circles since like forever, then having a small team decide that one of
these correct answers is now the preferred one and we're going with it
(after listening to all the arguments) hardly seems unfair to me.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> I have come to wonder if these two functions shouldn't be separated, in 
> different bodies (eventually with different nomination rules, etc.). This 
> "steering" question had also been phrased, slightly differently, by Mehdi, 
> during his DPL term, with the idea of a "Roadmap team". [As I understand it, 
> a 
> Roadmap team would pilot the Debian ship with a vision on how to sail the 
> sees, where the TC, when "steering", decides on a case-by-case in a ship 
> without captain]. Uncomfortable, for political and availability reasons, the 
> TC declined to take that role back then.

I hadn't looked at it from that angle before, but you're right. In fact,
if you look at other distributions, they all have some form of a
steering body: Ubuntu has their BDFL, Fedora has the FESCo, OpenSUSE has
an elected steering body, and FreeBSD has their core team. I'm sure much
of this is true for other distributions as well.

Debian does not have a body like this. In some way, this is a feature;
we don't have an overarching body that says "X, not Y", and therefore we
do both X and Y, and people can just use what they want. Sometimes,
however, that doesn't work; when X and Y conflict, we need someone to
choose one of the two options. The TC indeed isn't really set up to do
this properly, but it gets closest, and therefore it gets to do the job
by default.

If we are going to make a "steering committee" of sorts, however, or
adapt the TC so it can take the role, then I do think we should keep in
mind what our historic behaviour has been; that is, that we usually
allow multiple options to coexist, and that that isn't necessarily a bad
thing as long as they either don't conflict, or a default can be chosen
without too much disagreement.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Thinking about Delegating Decisions about Policy

[Wouter Verhelst]

On Fri, Sep 06, 2019 at 11:32:06AM +0200, Bill Allombert wrote:
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> > > On Wed, Sep 04, 2019 at 11:04:57PM +0200, Wouter Verhelst wrote:
> > > > >   * Most decisions are not just technical decisions, in many/most 
> > > > > cases
> > > > >   
> > > > > the decisions have answers that are all correct, but it just 
> > > > > depends
> > > > > on the weight of specific trade-offs. How those are weighted 
> > > > > depends
> > > > > heavily on each individual. This also seems rather unfair, as it's
> > > > > taking the natural and expected biases of a small set of people in
> > > > > the project and forcing them into the entire project.
> > > > 
> > > > Honestly, if the answers are all correct and we've been going around in
> > > > circles since like forever, then having a small team decide that one of
> > > > these correct answers is now the preferred one and we're going with it
> > > > (after listening to all the arguments) hardly seems unfair to me.
> > > 
> > > But then it become a steering committee and not a technical commitee.
> > 
> > Actually, it seems that the Technical Committee has kinda always been doing 
> > both of these things: arbitration, and steering.
>   
> The way the TC members are selected is not compatible with taking the role
> of a steering committee (which need to be properly elected rather than
> self-selected).

If we're going to change the rules about what the TC does -- or create a
whole new committee -- it makes sense to change this part of it, too. So
while I agree with you that this is a concern, it doesn't have to be a
fatal problem.

> (To avoid misunderstanding, I am not in favor of Debian getting a
> steering committee. The steering should come from the DPL, who is
> elected)

I agree that whoever does "steering" needs to be elected. However, I am
not convinced that one elected representative is good enough for that;
both for long-term stability (DPLs change up to once a year, which is
hardly enough for a long-term vision) as well as for allowing multiple
viewpoints (the DPL is just one person with his or her own biases; no
matter how well the DPL represents the viewpoints of the project at
large, it is always better to have multiple people in a position with
this kind of power).

So I think that Debian could have some limited benefit from a steering
group, but I do agree that it needs to be an elected group, not an
appointed one.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Wouter Verhelst]

On Wed, Oct 07, 2020 at 09:53:06PM +0200, Michael Biebl wrote:
> Forwarding this to the CTTE, just in case they have some input on this
> proposed plan.
> 
> 
>  Weitergeleitete Nachricht 
> Betreff: Re: Bug#946456: systemd: Provide systemd-sysusers as an
> independent package
> Datum: Wed, 7 Oct 2020 18:21:39 +0200
> Von: Michael Biebl 
> An: 946...@bugs.debian.org, Felipe Sateler , Ansgar
> , Niels Thykier 
> 
> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> `
> option('standalone-binaries', type : 'boolean', value : 'false',
>description : 'also build standalone versions of supported binaries')
> `
> 
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
> 
> Fedora decided to ship those binaries in separate binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
> conflict with the main systemd package, i.e. the main systemd package
> will continue to ship systemd-tmpfiles and systemd-sysusers linking
> against libsystemd-shared.
> 
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
> 
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
> 
> We could debate whether systemd-standalone-tmpfiles and
> systemd-standalone-sysusers should be provided by a single binary
> package, but since Fedora has already done this split this way, I would
> simply follow here and use the same binary package names.
> The relevant Fedora PR is
> https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
> 
> Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
> build variant (as with the udeb flavour), so build times shouldn't go up.
> 
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd

Probably stating the obvious here, but just in case:

Both systemd and the proposed new packages should also have a
"Provides:" header with something common so that packages that try to
use systemd-tmpfiles and/or systemd-sysusers can depend on that
something without requiring a 'Depends: systemd |
systemd-standalone-tmpfiles'?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Wouter Verhelst]

On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> [I don't need a CC, thanks]
> Hi,
> 
> > I know it was mentioned back in the day, but trying to re-ask it now:
> > Wouldn't it be possible to ship init scripts for compatibility purposes
> > from a sysvinit (or maybe a sysvinit-support) package? This would be the
> > inverse of what happened back when systemd was introduced, which was
> > about shipping service files that superseded existing init scripts.
> 
> I have thought about this, and it seems like a bad idea for a number of
> reasons, including:
> 
> 1) poor user experience - a package of initscripts would clutter
> /etc/init.d/ with a huge number of files (most of which would be no use to
> the user)

This could be fairly easily fixed.

Option one:
- Don't install the init scripts in /etc/init.d, but install them in
  /usr/share somewhere.
- Install a dpkg trigger that uses ucf to copy the relevant init scripts
  /etc/init.d (and goes through the rest of the dance to enable them)
  when the relevant package(s) is/are installed.
Option two: split up the initscripts package into multiple smaller
packages.

I don't think either of these are necessary, but if it's a concern,
there are ways.

> 2) init scripts to need to change sometimes, typically that change will
> accompany a version change in the associated daemon (e.g. the CLI changes) -
> the most natural way to have this work seamlessly is for the init script to
> come with the daemon

This puts the burden of maintaining said init script on the maintainer.
In my reading of the GR, that's not expected of maintainers anymore.

I think it's fair for a maintainer to be expected to file a bug on an
"init scripts" package if their CLI changes. The rest should then be the
job of the maintainers of that init scripts package.

> 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again
> making the daemon (source at least) package the natural place to keep it.

Yes, but does this also apply to network manager?

> 4) difficulty reliably achieving seamless handoff from daemon package to a
> putative sysvinit-scripts package (e.g. packages that actively remove the
> init.d file from the installed system; keeping a users' modifications to the
> file)

This might need some dependency trickery that I don't immediately have a
good answer for, but that I don't see as insurmountable.

Furthermore, it is my belief that if you are not running the default
init system, that then *some* level of ugliness is to be expected. At
the very least, you'd see systemd units on the file system that you're
not ever going to be using. I think it's unreasonable to expect the same
level of cleanliness and technical excellence as when your preferred
init system was still the Debian default.

> > I understand that you might not want that maintenance burden, however it
> > seems like the network-manager maintainers might not want that
> > maintenance burden either.
> 
> I think the burden concern is over-made here. This is not a case of "this
> init script has bugs that have been causing problems and no-one has fixed
> it", nor a bug report of the form "please write an init script". There is an
> extant, working init script.

Software changes. Environments change. Sometimes an init script stops
working due to changes outside the maintainer's area of responsibility.
This has happened to the nbd-client init script at one point, for
example (no bug, because I found it out myself and fixed it, but it did
happen).

Thus, maintaining an init script that the maintainer themselves doesn't
want to use or think is useful, imposes a burden of *at least* testing
it on the maintainer, for which they need a separate system (or, at
least, a VM) in order to do proper testing of the package with all that
implies. That's actually quite a bit of work, and it's not unfair that
the maintainer wouldn't want to do it.

If the init script is in the network-manager package, then the
maintainer is at the very least *expected* to make sure it keeps
working. If it stops working, where is the maintainer going to ask for
help? There is no guaranteed answer for the maintainer, and nothing they
can do other than accept bugs against their package that they then have
to set up a wholly separate system for just so they can fix a bug they
don't want to deal with in the first place.

If the init script is in a separate package, then the maintainer can
certainly give a heads-up to the maintainers of the separate package
when something changes in network-manager. It would not be unreasonable
to expect the network-manager maintainer to maintain a level of
communication with the maintainers of said initscripts package, and I
think you would have a *much* stronger case for complaining about
maintainers not wanting to support your pet project.

> There are people more than happy to provide assistance should it need
> updating. I concede that collaborating with those people is non-zero
> effort, b

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Wouter Verhelst]

On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> I think that we should either decide that
> 
> 1) NetworkManager should support elogind
> 
> or
> 
> 2) That we haven't seen enough development of alternatives to systemd
> and the project consensus on the GR has changed.

Personally, I think both of these options are terrible and will fail to
fix the situation long term.

There are people in Debian who would rather not see that they have to
carry init scripts in their packages. For better or for worse, these
init scripts are a relic of the past for such people, and they do not
want to have to work on them. And while Debian does have some ways of
collaborating across package boundaries, it's not really something we
are very good at, culturally. Given that the GR has given init scripts
lower priority nowadays, dropping the init script is not an RC bug
anymore, and therefore people in this group feel that it's just fine to
drop their init scripts and let people who care about alternatives deal
with the fallout of that.

At the same time, there are people in Debian who would rather not run
systemd on their systems, and who want to put in the work to make sure
that some alternative (of whatever form they prefer) is usable and
available in Debian. These developers seem willing to fix bugs when they
appear, but for reasons they've explained elsewhere in the thread are
unwilling to group all the sysvinit-specific stuff in a single package
and deal with it that way.

It feels to me that any solution that prescribes that people in the
first group need to do something which means they can't actually drop
the init scripts, or alternatively any solution which does not provide a
clear way forward for people in the second group on how they will be
able to do what they would like to achieve, is doomed to failure.

People in the first group are not going to magically change their mind
and want to put in the work. Any solution that prescribes that they have
to will fail the constitutional requirement that nobody can be forced to
do anything they do not want.

People in the second group are not going to magically change their mind
and want to stop using something not systemd. Any solution that
prescribes that they have to will fail the very same constitutional
requirement.

I think whatever the TC comes up with will need to incorporate the valid
needs and wants of both groups if it is going to succeed in settling the
argument.

Both the solutions which you suggest fail to meet this bar, from where
I'm standing.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Wouter Verhelst]

Hi Sam,

On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst  writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> I think that we should either decide that
> >> 
> >> 1) NetworkManager should support elogind
> >> 
> >> or
> >> 
> >> 2) That we haven't seen enough development of alternatives to
> >> systemd and the project consensus on the GR has changed.
> 
> Wouter> Personally, I think both of these options are terrible and
> Wouter> will fail to fix the situation long term.
> 
> You then go on to talk about init scripts.

If that is what you took away from my email, then I should probably have
written it differently so my message was clearer. Apologies about that.

I don't think that either elogind or init scripts are really the heart
of the matter here. What matters is that there are two opposing visions
about what Debian should become, that both these visions have valid
technical needs, and that deciding that we have to go with one or the
other isn't going to solve the issue; people will continue talking about
wanting to do what they want to do.

Debian isn't Fedora. Fedora has a "steering committee" (FESCo) which
decides on what to use in the future, and their word is final. If you
want to do something in Fedora that FESCo decided against, you're out of
luck. It means far less arguments, and there is something to be said for
doing things that way, but historically, it's not what Debian has done.
In my opinion, this diversity is one of our strengths, and making a
decision either way like you suggest is not going to help anyone.

> I found that really frustrating because I was talking about elogind,
> not init scripts.

Honestly, I don't think you can realistically do that. The no-systemd
people don't actually care about elogind; they only want it because
there is software out there which requires an interface provided by
logind, and elogind provides the same interface outside of systemd, and
so you can theoretically run NetworkManager without systemd if you
install elogind, or something along those lines. So while making a
decision about elogind may solve the bug at hand, it doesn't really
address the bigger issue, and then if we do that we'll be back here in
six months. Perhaps that's all we can do, but I do think it's worth
pointing out that it will happen.

As far as "developing alternatives" go: as I understand it, the end goal
for no-systemd people is not "something that doesn't exist yet".
Instead, the end goal is "we want to use what we have been using a long
time and what we thinks works just fine and we don't want this
newfangled mess, thank you very much". By allowing them to use elogind
but not init scripts, and then telling them that they have to write
something not-initscripts and also not-systemd if they want to move
forward within Debian, you're not saying something they want to hear.
That is, unless your end goal is to tell them to go do their thing
somewhere outside of Debian (which would be a valid position if it
happens to be how you feel about the issue, but it's not one I share).

In other words, I think the two are entangled, and I don't think you can
decide to only handle one of the two if you want to solve the issue at
hand.

(however, it is certainly possible to provide different solutions for
the two; e.g., you can say that the maintainer should add elogind as an
alternative dependency, but that init scripts should be elsewhere, in a
package maintained by no-systemd people)

> My reasoning doesn't apply to init scripts, I never said it did, and I
> even gave entirely different reasoning about init scripts because I
> don't think the text you quoted is a good place to think about init
> scripts.

My reasoning is that init scripts are the end goal, and that elogind is
just a symptom of that end goal, and that therefore talking about
elogind in isolation serves no purpose.

> The GR, policy, and our discussions treat elogind and init scripts
> differently.  I support the consensus of debian-policy, the and the
> majority of project members who voted in the GR in treating these issues
> differently.

I don't think that's actually the case; but the vote was rather muddled
because some options on the ballot were written by people who didn't
actually support the position they were writing, so I can't say for
sure.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Wouter Verhelst]

On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote:
> [0] to that end, orphan-sysvinit-scripts is in NEW,

Glad you're taking that route. I had been thinking of other things to
suggest that would make your life easier while allowing maintainers to
drop init scripts if they so desire, but I couldn't really come up with
anything better than that (except for a few very convoluted things that
don't really improve the situation).

> and while I hope your ruling will not result in a bonfire of perfectly
> good init scripts, I hope that maintainers who decide to ditch them
> will let us know so we can add them there

Maybe talk to debian-policy to come up with some wording to be added to
either the developer's reference or policy that discourages dropping
init scripts, but encourages talking to the maintainers of
orphan-sysvinit-scripts if for whatever reason it ends up being
necessary?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#978636: move to merged-usr-only?

[Wouter Verhelst]

On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> Also, as is has been discussed, if the /usr/doc/ transition was 
> representative then this would probably take many years.

You keep using that as an argument. I think it's very disinginuous to
point to a problem Debian had over 20 years ago[1] and say "look, we
don't know how to do this quickly". It's not like things haven't changed
since.

We can (and should, IMO) declare *today* that for bookworm, shipping
files in / (as opposed to /usr) that are not compatibility symlinks will
be RC.

You can start writing a lintian check today for the same.

If we take both these steps, this will only take us one release cycle,
and the dpkg maintainers can come up with a plan to remove /bin and
friends and replace them by symlinks in ways that will not confuse dpkg.

[1] the /usr/doc transition was in progress when I first joined Debian,
20 years ago. I don't remember the start of it, but I do remember it
ending.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Wouter Verhelst]

On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Control: severity -1 serious
> Control: tags = confirmed
> 
> CCing the release team, and CTTE because I don't know who else is
> tracking issues related to the usrmerge effort.  I've consciously chosen
> not to pour gasoline on the flame war by CCing anyone else (nor will I
> contact anyone else about the existence of this bug).
> 
> Steps I used to try to reproduce:
> 
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr.  Partition layout is:
>   sda1: ESP  fat32
>   sda2: /ext4
>   sda3: swap swap
>   sda4: /usr ext4
> 4. Selected only "Standard System Utilities"
> 5. Rebooted
> 
> Result: SUCCESS
> 
> Then, to test the rescue functionality:
> 
> 1. I discovered qemu+OVMF boot order is broken without changing the
>command to: kvm -L /usr/share/ovmf/ -m 2G -boot menu=on \
>-hda /scratch/debian-separate-usr-sda.raw \
>-cdrom /scratch/debian-testing-amd64-netinst.iso
> 2. Selected sda2
> 3. Yes, mount /boot/efi
> 4. Execute a shell in /dev/sda2
> 5. No usable shell was found on your root file system (/dev/sda2)
> 6. Changed virtual terminal
> 7. cd /target && ls bin
>ls: bin: No such file or directory
> 
> Result: FAILED
> Conclusion: This is a usrmerged system, and the rescue system does not
> support usermerged systems.
> 
> The options are, as I see them, ranked from least to most work-hours:
> 
> 1. Debian isn't yet ready for usrmerge.  Revert to normal system installation.
> 2. Reassign to src:rescue, and fix the rescue system.
>a) before chrooting, test for the presence of /target/bin/sh
>b) if /bin/sh is not found, either emit error to the user and present a
>   dialogue for selecting /usr partition, or
>c) parse /target/etc/fstab, and attempt to mount other partitions
>d) b & c will be difficult to implement when attempting to accommodate
>   the heterogeneity of possible MD, LUKS, and LVM layouts, not to mention
>   the complications introduced by the possibility of a user-configured
>   btrfs subvolume name "@usr" on any valid device.  Fstab parsing might
>   make the btrfs case easier with:
> i)   Display a dialogue selector if a btrfs partition is detected
>  The dialogue will list all detected subvolumes
> ii)  If the user cannot find a subvolume for "@usr", then
> iii) Allow the user to escape to the partition selection screen, and
> iv)  Unmount the partition
> 3. Disallow configuring of a mount for "/usr", and *Prominently* declare that
>Debian no longer supports separating /usr from /, declare this in *many
>places*, and reply to bugs on this topic for many years.  I put this one
>last because I believe the cost to work-hours is unbounded, and
>because I believe there may be a negative social cost associated with
>this action.  Also, if Fedora/RHEL/SUSE/Ubuntu support a separate /usr
>partition, then this action could make Debian look inferior.

FWIW, Debian was the last holdout in still supporting a separate /usr
partition amongst major distributions, so that bit is irrelevant...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

Hi,

On Tue, Mar 15, 2022 at 03:14:36PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See .
> 
> This escalation seems in direct contradiction to the tech-ctte decision
> in 994388. Moreover, this seems to effectively use package maintainer
> scripts as a means of directing a complaint at Debian users that has not
> gotten traction in other forums, and then directing such users at a wiki
> page that contradicts a prior project decision.
> 
> This does not even seem to be calling for help in any meaningful way.
> For instance, soliciting help updating dpkg to handle such
> configurations might have been more productive; that still wouldn't be
> appropriate in a maintainer script, but it might have been productive in
> a mail to -devel. But this isn't soliciting help, it's just incorrectly
> declaring the user's system broken.
> 
> This seems counterproductive and harmful.

FWIW, I think the TC should punt this bug to a GR.

The dpkg maintainer has chosen not to engage with the TC in #994388, and
now seems to be actively subverting a validly-made TC decision.

I do believe it reasonable to assume the dpkg maintainer has a point if
he believes that the currently-chosen way of moving forward is harmful.
However, the right way for him to make that point would have been to
engage with the TC, the body constitutionally placed to resolve
conflicts of this manner, not ignoring them and then doing whatever he
wants when the decision inevitably doesn't go his way.

I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
matter. It is not yet too late; the TC can always roll back decisions it
made earlier if it believes, in light of new arguments, those decisions
to be wrong. However, if this does not happen, then that does not
inspire me with confidence that whatever the TC decides after weighing
all the arguments available to them, the dpkg maintainer will follow
that ruling. Given that, in case the dpkg maintainer chooses to remain
silent again, I believe the only way forward is for the TC to recommend
a GR under §4.2.1 of the consitution.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 01:28:16PM +0500, Andrey Rahmatullin wrote:
> On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> > FWIW, I think the TC should punt this bug to a GR.
> > 
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> > 
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
> > 
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late; the TC can always roll back decisions it
> > made earlier if it believes, in light of new arguments, those decisions
> > to be wrong. However, if this does not happen, then that does not
> > inspire me with confidence that whatever the TC decides after weighing
> > all the arguments available to them, the dpkg maintainer will follow
> > that ruling. Given that, in case the dpkg maintainer chooses to remain
> > silent again, I believe the only way forward is for the TC to recommend
> > a GR under §4.2.1 of the consitution.
> This effectively means "TC cannot enforce its own decisions and everybody
> can ignore them". Also, who would enforce the GR results and how?

I suppose it does. Do you see a better way forward?

> Note that §2.1.1, at least in my opinion, forbids working against a TC
> decision, but doesn't say who would enforce that and how.

Exactly.

The nuclear option here is obviously to take maintenance of dpkg away
from the dpkg maintainer unless and until he decides to follow the
rules. I didn't want to suggest that (I don't think we're quite at that
level yet), but I'm pretty sure someone will put that option on the
ballot should this get to a GR.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 03:41:25AM -0700, Felix Lechner wrote:
> Hi,
> 
> On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst  wrote:
> >
> > The nuclear option here is obviously to take maintenance of dpkg away
> > from the dpkg maintainer unless and until he decides to follow the
> > rules.
> 
> This song is for Guillem:
> 
> https://www.youtube.com/watch?v=cnoX81TC6jk

(Stereo MC's - Connected)

I'm not sure what this is supposed to contribute to the discussion? I
think the current situation (where one person in a position of power
decides the rules don't apply to them) is extremely problematic.
Regardless of whether I think the dpkg maintainer is right in this
dispute (and I am inclined towards that position), I think the way he
has chosen to prove his point is not acceptable.

It fails §3 of the code of conduct ("Be collaborative"). Ignoring a
ruling of the TC and just doing your own damn thing is not conducive to
solving the problem. This, to me, is not acceptable.

It fails the "Our Users" bit of the "Our priorities" in the social
contract. Using user pressure to override a technical committee decision
that was taken, even if I may disagree with the merit of that decision,
is not acceptable to me.

Telling users to do one thing when the rest of the project has decided
to do another thing is *not acceptable*. Regardless of who you are.

You may think that the decision is wrong. That's fair. You are given the
option to express that opinion before this committee. If you don't
immediately have time to express that opinion, then you may request more
time. If you think there are other options possible but you need time to
write code to express those other options, then that's fine too and you
can say so.

But remaining silent and then just dropping a bomb like this is not
acceptable, in my opinion, and silly songs don't change that.

But hey, who am I...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 02:31:27PM +0100, Wookey wrote:
> On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:
> > 
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> > 
> > I do believe it reasonable to assume the dpkg maintainer has a point if
> > he believes that the currently-chosen way of moving forward is harmful.
> > However, the right way for him to make that point would have been to
> > engage with the TC, the body constitutionally placed to resolve
> > conflicts of this manner, not ignoring them and then doing whatever he
> > wants when the decision inevitably doesn't go his way.
> 
> > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> > matter. It is not yet too late;
> 
> That all sounds reasonable, but there is the long-standing issue that
> Guillem has never accepted that the TC has authority over the
> project. I forget the details, but given that he does not see it as
> valid it's not surprising that he is not engaging with it. 

Why does that matter? I honestly don't care.

Debian has a set of rules. It's called our "constitution". We all follow
those rules when we engage with the project, for instance when we are
voting.

wouter@pc181009:~/debian/webwml/english/vote$ grep 'guillem' */*voters.txt|wc -l
42

You don't get to exercise your rights in our constitution in one
instance but ignore your duties in another. The constitution exists, and
it is not an optional document. Either you agree by it (and then you get
to vote, etc), or you don't (and then what are you doing here). If one
party can get their way simply by ignoring the rules, then we might as
well pack up and forget this whole Debian thing even happened in the
first place.

There have been cases in the past where Debian has made decisions that I
disagreed with. There have been cases where I seriously considered
leaving the project. In the end, I chose not to do so, in part because
the rules we follow made the decision a fair one, even if I did not
agree with it.

For clarity, and again, I am inclined to agree with the dpkg maintainer
on the matter of how the /usr merge should be implemented; but I am
seriously offended by how he is acting in this manner. This is not how
things should be done.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#994388: dpkg currently warning about merged-usr systems

[Wouter Verhelst]

On Fri, Apr 08, 2022 at 12:07:25PM -0700, Sean Whitton wrote:
> Hello Wouter,
> 
> On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:
> 
> > Given that, in case the dpkg maintainer chooses to remain silent
> > again, I believe the only way forward is for the TC to recommend a GR
> > under §4.2.1 of the consitution.
> 
> Perhaps there is some appropriate GR that at some point it will be
> appropriate for the ctte to propose, but not one with the same text as
> one of our merged-/usr decisions already issued -- that doesn't make
> much constitutional sense, I think.

Well, I think it would -- the TC can always say "we want to get wider
input", and a GR is a proper way to do so, even if the GR is about the
exact thing the TC previously decided on (though that of course doesn't
need to be the case). Perhaps if there is a clearer project-wide
consensus about this, the dpkg maintainer might be convinced?

But that was just a thought, feel free to ignore it :-)

On a side note, the dpkg maintainer replied to my message, dropping the
-ctte Cc, wherein he claims that the warning has been removed:

https://lists.debian.org/debian-dpkg/2022/04/msg7.html

I didn't check any of the claims in his message, but it seems relevant
information.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: /usr-move: Do we support upgrades without apt?

[Wouter Verhelst]

On Wed, Jan 03, 2024 at 04:43:45PM +0100, Helmut Grohne wrote:
> On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > We can restore lost files in a postinst. For this to work, we must
> > duplicate (e.g. hard link) affected files in the data.tar.
> > Example: #1057220 (systemd-sysv upgrade file loss)
> > Note that this approach is not policy compliant for essential packages
> > as they must work when unpacked and this is relevant for gzip being
> > diverted by zutils for instance.
> 
> We'll be doing this anyway. It is implemented in systemd-sysv.postinst
> and proposed in the gzip patch above. Yes, we are technically violating
> policy for gzip then, but I don't really see a technical way not to
> violate policy. I expect that we do not consider fixing this (unfixable)
> policy violation release-critical.

I agree that this is the best way forward.

Presumably the reason for this requirement in policy is that without it,
debootstrap cannot function. That is, debootstrap first unpacks all
Essential packages, without running any preinst or postinst scripts, and
*then* runs all the maintainer scripts. If an Essential package would
not function without its maintainer scripts being run, then debootstrap
could fail halfway through.

Running debootstrap cannot trigger the issue, because it does not
involve upgrades; and I do not believe that apt will special-case
Essential packages other than that it refuses to remove them unless
the user enters The Phrase[1], so we can consider that if it's something
that would work for a regular package, it will work for an Essential
one, too.

Perhaps if the above assumptions are correct, policy should be updated
such that the requirement is relaxed to only apply for initial
installation?

[1] At least, I think it logically *should* not do so, but then I'm not
an apt developer and thus I may not know all the corner cases.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.