Re: [RFC] General Resolution to deploy tag2upload
Hi, On Wed, 2024-06-19 at 08:26 +0200, Ansgar 🙀 wrote: > > My understanding of the tag2upload developer position is that this > > requirement prohibits the goal of tag2upload. People who want to > > build the source package locally can already use the same algorithm > > today; that's what dgit is. The whole point of the tag2upload > > project is to remove the requirement that the package uploader > > install dgit or equivalent software locally and build the source > > package locally. This FTP team requirement therefore makes it > > impossible for tag2upload to proceed; any system that would have the > > required property would fail to accomplish the core goal of the > > tag2upload project. Therefore, this delegate decision is blocking > > the deployment of tag2upload. > > The code the tag2upload developers wrote is perfectly able to do that: > git-debpush, the tag2upload client by the tag2upload developers, > doesn't require dgit nor building the source package, and documented in > the initial mail about the GR to be used by people. It already looks at > patched and unpatched source trees (and checks that patches applies) > and compares them with the tree in Git. > > It could easily compute an integrity hash as well. > > Or is git-debpush itself incompatible with the goals of tag2upload? > What would a client-side compatible with the goals then look like? > > Will such a client be available before the GR? > > I hope the tag2upload developers requirements will not make it > impossible to proceed and they will not continue to block the > deployment of tag2upload. And thinking about this a bit more: we have an existing resolution mechanism for this blocker. The technical committee could overrule the git-debpush maintainers to include such a hash. This would unblock deployment of tag2upload for Debian, including the continued use of integrity verification by the archive (in its current scope limited to mostly dak). Ansgar
Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters
Hi, On Sat, 2023-09-16 at 12:58 -0700, Russ Allbery wrote: > Control: unblock 1051371 by 1050001 > > Ansgar writes: > > > However, there is a proposal by Jackson for an alternative filesystem > > layout based on symlink farms in consideration by the technical > > committee. This advocates removing compat symlinks in /bin, /sbin over > > time[1], thus requiring (c). > > This is not a correct summary of Ian's proposal. In the message that you > linked, Ian says: > > /bin and /lib etc. remain directories (so there is no aliasing). All > actual files are shipped in /usr. / contains compatibility symlinks > pointing into /usr, for those files/APIs/programs where this is needed > (which is far from all of them). Eventualloy, over time, the set of > compatibility links is reduced to a mere handful. > > I am absolutely certain that Ian would consider /bin/sh to be one of the > programs for which a compatibility symlink is needed, and one of the > remaining handful of links that would exist indefinitely into the future. > Indeed, he mentions /bin/sh explicitly later in that message. But the subject of this issue talks about "script interpreters", not just `/bin/sh` (which I guess is safe to assume would be one of the "handful"). It is unclear what files the Jackson symlink farm proposal would leave in /bin. Would /bin/python3 stay? Or would it stay first, but dropped at some later point? What about /bin/perl, /bin/zsh, /bin/env, ...? As far as I understand most compat symlinks should eventually be dropped (but which is unclear). Therefore doing (c) is safe, but anything else might use symlinks that eventually disappear. (And really: what about calling /sbin/ifconfig, ... as well? Here (c) is again the only safe solution with the Jackson symlink farming proposal.) It was asked to clarify the plan for this multiple times, sadly the proposers of the newly proposed filesystem layout have refused to give any answer so far. Ansgar
Bug#1050001: Bug#1051371: Post-/usr-merge paths for script interpreters
Control: block 1051371 by 1050001 Hi, On Tue, 2023-09-12 at 20:48 -0700, Russ Allbery wrote: > I think the root problem behind this bug is that it is revealing we have > not made a decision about /bin and /usr/bin path references in Debian > after /usr-merge. Various people, myself included, made assumptions about > what the policy would be, but we never actually decided anything that I am > aware of and people's assumptions are not matching. I think we need to > talk about this directly, after which what to do with this bug will > probably become obvious. > > So far as I can tell, there are three main possibilities: > > (a) Although /bin and /usr/bin are merged (and likewise for the other > merged paths), Debian will continue to require (or at least recommend) > use of /bin paths for things such as /bin/sh that historically used > those paths. > > (b) Since /bin and /usr/bin (and likewise for the other paths) are merged, > /bin/sh and /usr/bin/sh are equivalent. Packages can use whichever > path they want, and Debian will end up with a mix of both references. > > (c) Although /bin and /lib technically work due to the aliasing, they are > deprecated and everything in Debian should stop using those paths. > All paths should point to /usr/bin and /usr/lib now. As far as I understand people wanting merged-/usr want (b) (I do). There have been people advocating (a) in this bug. However, there is a proposal by Jackson for an alternative filesystem layout based on symlink farms in consideration by the technical committee. This advocates removing compat symlinks in /bin, /sbin over time[1], thus requiring (c). The technical committee should therefore probably be aware of this policy issue in their consideration of #1050001; the resolution of which might also cover this issue (#1051371). Ansgar [1]: https://bugs.debian.org/1050001#33
Bug#1050001: Third-party tooling support for merged-/usr vs symlink farms
Hi, On Fri, 2023-09-01 at 13:42 +0100, Luca Boccassi wrote: > the claim that Ansible, Puppet, Chef, Docker, Rsync and whatnot no > longer work on Debian/Ubuntu/Fedora/Arch/SUSE/CentOS/RHEL/etc I think this is a valid point that should be discussed. How do third-party tools cope with merged-/usr (as implemented in Debian and elsewhere)? And how is the support for the proposed symlink farm layout? Has anyone done prior investigation on this? Are there already experimental systems converted to the new layout or some way to convert an existing system to this for testing (not on a production system)? It might be interesting to experiment with the new layout. Ansgar
Bug#1050001: Practical problems with proposed symlink farming: diversions
Hi, a practical thing with usrmerge and legacy layout[1] is the following: assume you do not want programs to find a specific program via PATH lookup or even a fully-qualified path. Then a user can just divert that single program away (or just remove it, depending on details). With Jackson's proposed symlink farms this property goes away: users now have to handle both the copy in / and /usr! What is worse: both entries could be managed by different means (shipped by the package, created by maintscript, created by some external process). This will probably cause breakage with third party integrations of management systems like Ansible. It also seems like a nice property that I don't see any convincing reason to lose so far; we should try to keep the system simple and not introduce such complexities without reason (and rigorous reasoning that it is safe to do so!). Any thoughts about this? Ansgar [1]: With some exceptions such as some programs have compat symlinks in the legacy layout or between .../bin and .../sbin.
Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]
Hi Ian, On Wed, 2023-08-30 at 12:52 +0100, Ian Jackson wrote: > Debian has historically been simply much more reliable. Could you quantify this? This is not my experience. As far as I understand you often use non-standard configurations (split-/usr, non-standard init system, ...) which might explain your impression. But non-standard ocnfigurations have been less reliable since forever. > usrmerge is a facet of Debian's culture wars. I would appreciate keeping the discussion to technical parts; could I ask you to keep your concerns about cancel culture elsewhere? > > > This argument is basically drawing together the common Affected > > > tooling includes not just our .debs, but also remote > > > configuration management systems like Ansible, image construction > > > (Dockerfiles), and 3rd-party software installation progrmas > > > (including > > > both 3rd-party .debs and 3rd-party script-based installation > > > systems). > > > > I don't follow the reasoning. [...] > > Sam has posted a helpful set of examples of things that one might do, > whose consequences with aliased directories are unclear. > > These are of course only examples. Tools like Ansible, Dockerfiles, ... have probably already been changed to handle merged-/usr. If they are still horribly broken, please document major issues (there are probably always cases that need a change). I somehow doubt many tools will be broken on many distributions for many years and nobody caring. So please substantiate this claim; it seems wild speculation that tools no longer work on Debian, Ubuntu, Red Hat, SuSE, Arch, Gentoo, ... and that they haven't been changed to work (in so far as this has been neccessary). I see this more as a reason against moving to the proposed Jackson layout with symlink farms: this new layout seems more likely to introduce problems with tooling like Ansible, Docker, ... than an existing layout shared between most(?) larger distributions and already the default for many years. Is there any risk evaluation what happen when moving to symlink farms? > > * Become more precise about what your layout looks like precisely. > > Our > ... > > Let me give some examples to get you started: > > libreoffice -> /bin/python > > ghostscript, imagemagick, mesa -> /bin/env > > bind9, manpages, net-snmp, qtbase-opensource-src -> /bin/perl > > Of these I would hope (by, say, 2033) to only include env. I think "hope" is not a good decision mechanism to produce a high quality operating system. How do you plan to do this? Drop links by throwing a coin, releasing stable, then waiting for user systems to be broken? This has been asked several times, but you refuse to give any answer. > perl upstream doctrine used to be that /usr/bin/perl was the correct > canonical path. I haven't checked if that recommendation still > stands. > > I don't know what Python upstream doctrine is on /bin vs /usr/bin; if > it were that Python is supposed to be in /bin, then we might need to > follow that. (But, are they dropping support for the BSDs?) > > With another hat on in an upstream project I've have been receiving > patches to change #!/bin/bash in CI scripts to #!/usr/bin/env bash. How do you ensure all users follow this scheme required by your proposed symlink farm layout, including for local scripts or scripts taken from systems where they just work? > I think it's worth pointing out that any software which is trying to > be portable to Unix systems other than just Linux (which includes the > BSDs and MacOS) will need to avoid assuming directory aliasing. Which seems irrelevant for what we do in Debian. On portable system you can't assume `/bin/sh` to be there either... Ansgar
Bug#1050001: Unwinding directory aliasing [and 3 more messages]
Hi Matthew, On Sun, 2023-08-27 at 11:30 +0100, Matthew Vernon wrote: > Any such consideration must be mindful of the fact that the majority of > Debian installs are now /usr-merged, which means that the complexity of > unwinding such installs has to be a heavy factor in thinking about > alternative approaches. Yes, I think there are many technical challenges required before Debian would be in a position to adopt the proposed Jackson filesystem layout. If Debian would choose to adopt it at all (an open question). Besides conversion, there is also the telemetry service that seems to be required to safely move to the proposed layout (AFAIK no alternative to this has been proposed yet). I'm not sure if there is already any work done on the path by the proposers? I'm also still missing an overview what the Jackson layout's advantages over the existing filesystem layout (merged-/usr) or the 2000's layout is (split-/usr). As far as I can tell it combines the disadvantages of both with much additional work required to get to it; I don't really see any advantage so far (besides "our tools can't handle anything else", but in practice it seems to work fine, and of course avoiding stuff associated with a certain company which I understand is a goal in itself for some people)... I would appreciate a list of technical and ideological reasons why switching to the Jackson layout is important for Debian. Ansgar
Bug#1050001: enabling telemetry to track usage of /bin compat shims?
On Wed, 2023-08-23 at 20:50 +0200, Ansgar wrote:
> > /bin and /lib etc. remain directories (so there is no aliasing). All
> > actual files are shipped in /usr. / contains compatibility symlinks
> > pointing into /usr, for those files/APIs/programs where this is
> > needed
> > (which is far from all of them). Eventualloy, over time, the set of
> > compatibility links is reduced to a mere handful.
[...]
> How do you decide when to remove a link? Is there a simple mechanism to
> detect when users no longer use it?
I thought about this a bit. A possible solution might be using a small
wrapper program in /bin that tracks usage of the compat shim (possibly
together with minimal information about the callee) plus a telemetry
service collecting this data and submitting it to Debian.
The shim should also look at $PATH and make some educated guess whether
it was invoked explicitly using /bin/${something} or just as
${something} and PATH lookup would have found /usr/bin/${something}
either way.
To get accurate data, this should be enabled by default (with
possibility to opt out).
I think solving this issue is crucial before we can agree on proceeding
the proposed switch to the Jackson filesystem layout.
Ansgar
Bug#1050001: Unwinding directory aliasing
Control: retitle -1 migrate from merged-/usr to new alternative filesystem layout On Thu, 2023-08-24 at 13:36 -0600, Sam Hartman wrote: > > > > > > For myself, I think the issues raised in DEP17 are significant enough > that I would at least read a proposal to explain a different way to get > to a merged /usr system. > I.E. yes, I believe that something has changed significantly enough that > I would be willing to read proposals for alternate ways to get to the > end goal we've agreed to. > > However: > > 1) Jackson is not making such a proposal. Yes, we are talking about migrating all installations to a new, alternative filesystem layout now. Which was mentioned years ago already and dismissed (for reasons). The proposal to move to this alternative layout and why one would want to do so hasn't seen any recent discussion before coming to the tech- ctte as far as I know. If someone wants to go this way, I suggest to just have a GR about it instead of iterating this at tech-ctte yet again. It's not very motivating to have some people endlessly argue against moving forward and wanting to revisit/reverse/change some decisions endlessly. Ansgar
Bug#1050001: Unwinding directory aliasing
Hi Simon, On Wed, 2023-08-23 at 20:12 +0100, Simon McVittie wrote: > I'm keen to avoid the anti-pattern where a valid technical point gets > disregarded or even opposed because the way it was expressed puts > other project members on the defensive. [...] > I alluded to that in a previous mail to this thread, but I don't have > first-hand knowledge of the specifics of how that went, and it sounds > as though you might. Do you have references that you can point us to? > (To the list or as private email for me to summarize on-list later, > whichever seems more appropriate. Does it matter? Is it worth investing time into investigating this? Or are we not really considering moving to the proposed Jackson filesystem layout? (In which case it's probably not worth investing time to look what SuSE did in detail.) And the more important question: how often do we want to rehash the usrmerge discussion? At some point we should stick with a decision and not endlessly restart discussions (unless something really significant changes, but I don't think this is the case). *mumble* leadership something *mumble* If we want to restart discussions, we can talk about init system support in Debian and costs/benefits of supporting some of them. :-) Ansgar
Bug#1050001: Unwinding directory aliasing
Hi,
On Wed, 2023-08-23 at 17:04 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
>
> Desired end state
> =
>
> This is a very good question. I had a very constructive conversation
> with Helmut via video chat. It seems that there's a misunderstanding
> about the desired end state.
>
> My idea of a desired end state is as follows:
>
> /bin and /lib etc. remain directories (so there is no aliasing). All
> actual files are shipped in /usr. / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is
> needed
> (which is far from all of them). Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.
Cool, so we need to touch all packages shipping packages in /usr/bin to
also include a /bin symlink? Like /bin/python3 -> /usr/bin/python3?
(And yes, users use these, so they are necessary unless you want to
break working systems; if so please provide good reasons).
How do you decide when to remove a link? Is there a simple mechanism to
detect when users no longer use it?
> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.
Why should we invent again another, incompatible filesystem layout?
Is there any good technical reason to do so? One that was not discussed
already?
Sorry, I feel like we are going back ignoring any discussion in the
last years and would invite you to read what was discussed about these
approaches in previous discussions first. So far it looks like NIH
syndrome, similar to the need to invent yet another daemon readiness
protocol when systemd was the topic.
> Looking towards the future
> --
>
> It seems to me that directory aliasing will continue to be a source
> of very annoying bugs indefinitely, well after the transition is
> fully complete. In another 20 years we'll still be debugging strange
> installation breakage that will turn out to be due to directory
> aliasing.
But introducing an incompatible filesystem where we only detect that
something references files in the wrong path (as presumably only a
random subset will be in /bin) will not give any bugs?
We already *had* these bugs for several releases and found them only
after release (even before usrmerge which makes them non-bugs).
Please provide a plan how to fix these ahead of time; please be aware
that they might only occur with some hardware / configurations.
Ansgar
Re: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, 2023-07-16 at 12:54 +0100, Simon McVittie wrote: > On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > > In the meanwhile, I'll immediately revert the sabotage. > > Both of you, please don't turn this into an NMU war in the archive: > that doesn't benefit anyone. I would have preferred it if Adam had not > immediately uploaded a 0-day revert, but preserving the status quo from > bookworm is not the worst state to be in while we discuss this. No, we should just have made a decision a long time ago and not go back and forth the entire time. That we do not do that shows lack of leadership in Debian. (And yes, you can reconsider stuff, but the barrier to stop a process and reconsider it again should not be zero and probably higher the later one does block progress.) > If Adam's concerns about this change are valid, then we should address > them, either by doing something different in debootstrap or by reporting > bugs against affected packages. I guess Adam could go ahead with the GR he wanted to bring up the last time he did NMUs this way (for reverting enabling usrmerge by default on upgrades). I would like to ask Adam to stop interfering with usrmerge until that long announced GR is there (and note that if we waited for that GR to happen as Adam demanded then we would still be waiting). > If Adam's concerns about this change turn out to be unfounded, then we > should reinstate my change (as NMU'd by Luca) in a calm and considered > way, and all we will have lost is a few days of progress and a few bytes > of changelog. That is false in so far as that only considers technical changes we get. However we also lose more and more energy/motivation/* even if we eventually go ahead as planned, i.e., social costs are not considered, but should be (IMHO). Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Matthew Garrett writes: > With my non-CTTE hat on, I think this is a demonstration that Debian > *does* care about derivatives. It's important to ensure that derivatives > are aware of the subtle interactions between dpkg and usrmerge, > otherwise they may suffer from hard to diagnose issues on upgrades. The > message from dpkg says nothing about reverting to split-/usr, and > instead points at a wiki page. If our documentation on how to avoid > these issues is incomplete (ie, if we're only describing how to avoid it > by using split-/usr rather than describing the mitigations we've imposed > within Debian to avoid triggering the issues), perhaps a better approach > would be to improve that documentation? We don't benefit our users by > pretending there isn't a problem here. Okay, I followed your recommendation and added a small warning to the FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=78&rev2=79 Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote: > After discussing this at our monthly meeting, we concluded that the > technical committee isn't going to take action on this at the moment. > There's a legitimate technical consideration behind the warning, and > it's necessary for derivatives to ensure that they handle the > associated scenarios properly. Okay, I take that as "Debian doesn't care about derivatives". Suggesting users to revert to split-/usr *will* break stuff for users once more code Debian assumes merged-/usr. > While those underlying technical issues exist, we > think it's premature for the committee to intervene on this specific > issue. Okay, I guess the very long drama about this last year was not sufficiently long and we did not discuss it in sufficient detail. I'm a bit disappointed how the ctte appears to do as much as they can to avoid deciding on this :-( Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, 2023-06-06 at 11:04 +0100, Sean Whitton wrote: > I don't think the TC has or should have any authority over dpkg > upstream, but with dpkg being a native package, any implementation of > our decision for the Debian archive is also implemented for dpkg > upstream. And it might be that the dpkg developers would be against > the TC override solely or mostly because of this fact. So possibly > changing that would resolve things peacefully. Given the Debian project owns dpkg.org, the upstream mailing list is @lists.debian.org, official releases are published on deb.debian.org and so on, I think the Debian project *is* the upstream for dpkg. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
On Fri, 2023-05-26 at 08:39 +0100, Matthew Vernon wrote: > > So let me summarize Debian's "official" position as I understand it: we > > do *NOT* care how dpkg's recommendations will break derivative > > installations at all; if systems become unbootable, cause data loss, > > ... now or in the future that is explicitly fine. > > This is also unhelpful (and incorrect). No, it is correct. We allow boot-critical parts to refer to files using either the path in / or /usr; on systems following the recommendations from dpkg's warning this might result in non-booting systems. That is what we sign up to accept by having the warning in dpkg. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Russ, On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. My impression is that the tech-ctte disagrees on this point and would not want to reverse the mistake, but double down on it (in your words). Or rather my impression is that they would like to avoid any decision on the dpkg mess situation. (Though not making a decision when asked is of course also an explicit decision.) So let me summarize Debian's "official" position as I understand it: we do *NOT* care how dpkg's recommendations will break derivative installations at all; if systems become unbootable, cause data loss, ... now or in the future that is explicitly fine. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote: > On a process level, I think I miss attempts to resolve this with the > dpkg maintainer in a constructive way. The patch was already suggested to the dpkg maintainer and rejected. > Does anyone mind just closing the bug? Yes, I do. Please pass a resolution that you don't want to override the dpkg maintainer and that telling derivative users to configure their system in a way that will cause breakage is okay to do for packages in Debian. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On Fri, 2023-05-19 at 07:09 -0700, Sean Whitton wrote: > On Thu 18 May 2023 at 07:55PM +02, Ansgar wrote: > > > Why not? > > We will not move that fast. So there is no real reason? As there doesn't seem to be anything you think need to be talked about that is missing to get to a decision (given you ignored all other questions multiple times). Do you expect this to take longer than 2-3 months? I would suggest to just use a GR in that case: it seems quicker and less painful than a multi-month long process for a simple(!) question. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Thu, 2023-05-18 at 12:14 -0600, Gunnar Wolf wrote: > Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]: > > Why not? > > > > Do you think the implications of removing the warning are unclear? > > > > Do you think we need to explore alternative solutions? > > (I am no longer part of the Committee, answering just as another > developer) > > dpkg has many bits that make it special. It has been discussed whethe > dpkg should be a native package or it should become non-native; if it > were non-native, having a patch that contradicts the upstream > author's wishes would be easier (and I'm not saying that I'd be up > for patching this warning out as it is). Do you think this implementation detail is relevant for what we do in Debian? I don't care how a patch is applied and don't think that detail has to be part of the decision. I also don't see any further active discussion on this aspect (unless I missed something). > If we were to force a patch silencing out this warning right now and > for all of the Bookworm cycle, and the dpkg authors disagree with it, > they could remove (even omit to include it) in any updates. So? That is the case with any ruling the ctte makes, including the non- binding one the ctte just did under Constitution 6.1.5. > Upstream > has repeatedly expressed their opposition to the way usrmerge has > been brought forward, and the warning silenced specifically for > Debian is already the best compromise situation we have been able to > reach -- even though we are aware the situation is far from ideal. If the best solution we have been able to reach is telling users of derivative distributions to configure their system in a way that is expected to cause breakage, then it would be worth documenting that this is the case and we cannot do more for derivative users. If the ctte believes this to be fine, then the ctte can decide to not overrule the maintainer. I don't think this is a good reason to delay the decision indefinitely unless there is some reason to believe something will change within a reasonable period of time (which I don't see happening). Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On Thu, 2023-05-18 at 10:48 -0700, Sean Whitton wrote: > On Thu 18 May 2023 at 07:21PM +02, Ansgar wrote: > > > The full freeze is approaching and there has been no progress on > > this > > issue. Does the ctte think a decision before the release is still > > possible? > > Not speaking for the whole ctte, but I don't think that is possible. Why not? Do you think the implications of removing the warning are unclear? Do you think we need to explore alternative solutions? Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi, On Thu, 2023-05-11 at 00:32 +0200, Ansgar wrote: > On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > For derivatives based on Debian stable it might be worth having this > included in the next stable release; this would need a fairly quick > decision on this issue. The full freeze is approaching and there has been no progress on this issue. Does the ctte think a decision before the release is still possible? As asked earlier I'm also interested in whether the ctte thinks there is enough consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? I admit not having read all mails in the thread as it went fairly off topic IMHO. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote: > On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > This would require a new, maintainer-overruling vote. > Our existing decisions do not apply, so far as I can tell. Yes, I agree. > I have written a separate message to the bug and to debian-dpkg with > a proposal to avoid having to have such a vote. That seems to be about an implementation detail on how to apply the patch. I don't think that is the core of the issue? The core issue as I see it is as follows: - Debian has decided to support only merged-/usr, including possibly moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 as the interpreter in binaries. - This change breaks on non-merged-/usr systems, including derivatives that do not revert *all* relevant changes. (Do you know one that does this or plans to do so?) - dpkg recommends derivative users to move to non-merged-/usr. I think this contradiction is not good and the core conflict. For me a distribution should have some coherence. It is not just a distribution of unrelated parts (like linux, libc, dpkg, dash, ...), but also integrates them to work together. And this also means not one package telling users to do X which breaks other packages. Or (if other packages would do similar things as dpkg) one package asking users to do X and the other asking users to do the opposite of X. Just imagine dpkg asking users to move to split-/usr and then another package starting to warn users to move back to merged- /usr. Would that be a good state? I think not which is why this bug exists. Do you think this summary of the issue is right? Is there some consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote: > Cool, then let's ask tech-ctte. > > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. > > Thanks, > Ansgar > > [1]: https://bugs.debian.org/994388#397 For derivatives based on Debian stable it might be worth having this included in the next stable release; this would need a fairly quick decision on this issue. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Package: tech-ctte X-Debbugs-Cc: Russ Allbery , Sean Whitton , Helmut Grohne , Luca Boccassi , debian-d...@lists.debian.org, debian-de...@lists.debian.org On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. Cool, then let's ask tech-ctte. Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Thanks, Ansgar [1]: https://bugs.debian.org/994388#397
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Russ, On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote: > Ansgar writes: > > As far as I understand, we do explicitly *not* care about our > > derivatives with regard to merged-/usr as some packages in Debian > > recommend users to move *away* from merged-/usr to split-/usr on > > derivatives, i.e., to an unsupported fs layout. > > Caring about them isn't the same thing as doing everything they want. We > can both try to make things as smooth for them as possible and still make > design decisions about Debian that they may disagree with or that may make > some property they want to maintain difficult or impossible. It's the > sort of decision we have to make on a case-by-case basis. Debian going out of its way to tell derivative users to switch back from merged-/usr to split-/usr is the *opposite* of trying to make things as smooth for them as possible. I asked the ctte to consider not telling derivative users to revert from merged-/usr and was told me that "we [ctte] would not consider this [change] to be in line with our existing decisions" (informally). I take that as explicitly not caring that we break derivative users' systems. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote: > On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote: > > Debian's dependency system requires to explicitly declare > > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we > > cannot do > > that for packages outside Debian's ecosystem. > > > > The same is true for diversions/alternatives/* or anything else > > requiring coordination among all users: the dpkg ecosystem has too > > many > > practical limitations to support non-Debian packages on anything > > but a > > "it might work" basis (which is usually "good enough"). (This is > > even > > true for packages within the Debian ecosystem, especially when one > > considers partially implemented features like multi-arch.) > > I don't think this is the consensus view. So why do we allow changes that require listing all reverse dependencies in Breaks then? This is known to be wrong for all non- listed packages, e.g., all local/vendor/derivative-specific packages. > Our derivatives are among our users, for example, and we care about > them being able to add packages in appropriate ways. As far as I understand, we do explicitly *not* care about our derivatives with regard to merged-/usr as some packages in Debian recommend users to move *away* from merged-/usr to split-/usr on derivatives, i.e., to an unsupported fs layout. AFAIR the ctte felt that doing so on derivatives is fine for packages in Debian (w/o an explicit formal ruling). Ansgar
Bug#1020923: tech-ctte: please clarify if atomic updates are required
On Wed, 2022-09-28 at 13:05 -0700, Sean Whitton wrote: > On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote: > > Package: tech-ctte > > X-Debbugs-Cc: Zack Weinberg > > Control: block 1020920 by -1 > > > > Hi, > > > > please clarify if atomic updates are mandatory for the Debian system. > > Or other measures to ensure that system crashes at *any* time do not > > render a system unbootable. > > > > See also: https://bugs.debian.org/1020920 > > (1) Do you mean any package update? Certain packages? dist-upgrade? Any package relevant for successful boot. Any upgrade. As far as I can tell, the submitter requires some guarantees significantly stronger than what Debian requires for essential packages. In particular, boot-relevant packages are demanded to work in unconfigured state, with not fully satisfied dependencies (possibly not even unpackaged?), in partly unpackaged states, after maintainer script errors, and all of that in combination with system crashes that might result in partly written data to filesystems. And possibly in other interesting system states too. > (2) The TC is a decision-making body of last resort. The bug you > mention was filed today. Might this be premature? Well, if we close it or don't act on it, people will complain and/or demand to remove us from Debian for not acting on it (the latter might be limited to people just sitting on their porch). The other tech-ctte bug about usrmerge also suggested it would just end up here either way. Ansgar
Bug#1020923: tech-ctte: please clarify if atomic updates are required
Package: tech-ctte X-Debbugs-Cc: Zack Weinberg Control: block 1020920 by -1 Hi, please clarify if atomic updates are mandatory for the Debian system. Or other measures to ensure that system crashes at *any* time do not render a system unbootable. See also: https://bugs.debian.org/1020920 Thanks, Ansgar
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On Wed, 2022-09-28 at 12:29 -0400, Zack Weinberg wrote: > 1. Is there already a rule (or multiple rules) somewhere that forbids > the existence of pairs of packages where one ships /X/Y and the > other ships /usr/X/Y, where X is a directory on non-merged-/usr > systems and a symlink on merged-/usr systems, and Y is any name? *sigh* There has been such a rule for many, many years already. I really feel you lack investigating the issue before filing yet another ctte bug about it. Ansgar
Bug#994388: Bug#1008489: dpkg: postinst should not warn about Debian's default (and soon only supported) filesystem layout
On Sat, 2022-04-09 at 11:01 -0700, Sean Whitton wrote: > Okay I see. > > To answer your question, then, the ctte has not even discussed the > relevance of warnings to derivatives. Well, the ctte has mostly discussed things in private. I have no idea and it's not possible to comment on what the ctte might or might not have discussed and might or might not have missed. Impact on derivatives seems an obvious topic to me. > I can't speak for everyone, but I > suspect that we would not consider this NMU to be in line with our > existing decisions. I look forward to seeing discussion on this or a summary of previous private discussion results. Ansgar
Bug#994388: Bug#1008489: proposed diff for dpkg 1.21.7+nmu1
On Sat, 2022-04-09 at 10:59 -0700, Sean Whitton wrote: > On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote: > > I've prepared a patch for the current issue. See the attached proposed > > NMU diff. I've limited it to minimal changes. > > I don't understand. The warning is already no longer emitted on > Debian? Debian is used as a basis by derivative distributions where it is still emitted. Most derivatives will likely follow Debian (unless you expect a significant number of them to have resources to fork and maintain packages for continued split-/usr support). I think it is reasonable for Debian packages to behave reasonably on derivatives as well. In this case that means dpkg should not emit a warning by default on derivatives either. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Sat, 2022-04-09 at 14:52 +0200, Wouter Verhelst wrote: > 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 So one of the statements there is: | The TC ruling stated that Debian supports for now both layouts So maybe the dpkg maintainer just missed that we decided to only support merged-/usr starting with bookworm? Guillem, please read https://bugs.debian.org/978636#178, relevant part quoted below: |The Technical Committee resolves that Debian 'bookworm' should |support only the merged-usr root filesystem layout, dropping support |for the non-merged-usr layout. Maybe the misunderstanding will be resolved with this. Ansgar
Bug#994388: proposed diff for dpkg 1.21.7+nmu1
Hi,
I've prepared a patch for the current issue. See the attached proposed
NMU diff. I've limited it to minimal changes.
Is this something the technical committee finds acceptable?
Ansgar
From 2569c0aca93f2f0d7f5521c3158ed077f206ce0a Mon Sep 17 00:00:00 2001
From: Ansgar
Date: Sat, 9 Apr 2022 11:14:40 +0200
Subject: [PATCH] dpkg.postinst: Remove warning about merged-/usr. Closes:
#1008489
---
debian/changelog | 7 +++
debian/dpkg.postinst | 38 --
2 files changed, 7 insertions(+), 38 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 6375989..a316609 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dpkg (1.21.7+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * dpkg.postinst: Remove warning about merged-/usr. Closes: #1008489
+
+ -- Ansgar Sat, 09 Apr 2022 11:00:38 +0200
+
dpkg (1.21.7) unstable; urgency=medium
- The “Social Contract §3: We will not hide problems”
diff --git a/debian/dpkg.postinst b/debian/dpkg.postinst
index 83a4873..5aee110 100644
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -9,42 +9,6 @@ PROGNAME=dpkg
setup_colors
-get_vendor()
-{
- local origin="$DPKG_ROOT/etc/dpkg/origins/default"
- local vendor
-
- if [ -e "$origin" ]; then
-vendor=$(sed -ne 's/^Vendor: *\([^ ]\+\) */\1/p' "$origin" | tr '[A-Z]' '[a-z]')
- fi
-
- echo "${vendor:-default}"
-}
-
-check_merged_usr_via_aliased_dirs()
-{
- local vendor
-
- vendor=$(get_vendor)
-
- # In Debian some people have gotten so offended by the following _warning_
- # that they have resorted to bullying and abuse. Life's too short, sorry.
- if [ "$vendor" = "debian" ]; then
-return
- fi
-
- for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
-linkname="$(readlink $DPKG_ROOT$d || true)"
-if [ "$linkname" = "usr$d" ] || [ "$linkname" = "/usr$d" ]; then
- warning "This system uses merged-usr-via-aliased-dirs, going behind dpkg's"
- warning "back, breaking its core assumptions. This can cause silent file"
- warning "overwrites and disappearances, and its general tools misbehavior."
- warning "See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>."
- break
-fi
- done
-}
-
# Version 1.21.0 had bogus handling of DPKG_ADMINDIR in update-alternatives,
# and misplaced them, fix them up.
fixup_misplaced_alternatives()
@@ -93,8 +57,6 @@ fixup_misplaced_alternatives()
case "$1" in
configure)
fixup_misplaced_alternatives
-
- check_merged_usr_via_aliased_dirs
;;
abort-upgrade|abort-deconfigure|abort-remove)
;;
--
2.35.1
Bug#994388: dpkg currently warning about merged-usr systems
Hi Helmut, On Fri, 2022-04-08 at 20:04 +0200, Helmut Grohne wrote: > We vehemently disagree on how severe those bugs are, > but at least we've stopped selling them as features it seems. Could you please give examples where such "selling as a feature" happened? Please point to somewhere where someone said the file disappearing bug (w/ moving between packages & locations) is a feature or similar things. > So sooner or later, we want dpkg fixed. Now the ctte cannot tell > anyone to fix dpkg. All it can do is select between available > options. Well, the ctte was asked about the warning added[1]. It has so far not chosen between available options, such as removal of these warnings. (I think we do derivates a disservice if dpkg emits these warnings there.) [1]: https://lists.debian.org/debian-ctte/2022/03/msg00017.html > And while Guillem has his own reasons on disliking the existing patch > everyone else basically agrees that it is not ready for other > reasons. If that patch were to be decided upon by the ctte in its > current form, the answer would most likely be "no", not due to change > in principle, but due to the patch being unfinished. So talk about that when it happens? As far as I can tell from the last meeting agenda, the technical committee doesn't seem to see much technical issues with usrmerge. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, 2022-04-08 at 14:31 +0100, Wookey wrote: > At this point I am more disappointed in the people who keep insisting > that 'it mostly works' is good enough, than I am in the bloody-minded > dpkg-maintainer. Debian is not a 'mostly works' project. We do things > properly - or at least we used to, even if that takes a long time. > > Some people have cited the multiarch dpkg changes as an example of > work on dpkg being difficult. I was quite closely involved in all > that and yes it took a long time but it was done right in the end, > and it was the dpkg maintainer who insited on it being done right. No, multiarch is in the "mostly works" state. If you wanted to do things "properly" (whatever that means), we would still not have multiarch (given the bugs are not fixed). Ansgar
Re: Bug#994388: dpkg currently warning about merged-usr systems
On Tue, 2022-03-29 at 08:24 +0200, Helmut Grohne wrote: > That is unfortunate. If I remember correctly, there was some more > concrete criticism that is still entirely unaddressed in the current > form. > > dpkg is both a Debian package and an upstream project used by > multiple distributions with different needs. Guillem generally cares > for the needs of other distributions. As a result, dpkg separates > policy from mechanism in a lot of places. The patch at hand however > fully intermingles them. Which directories are to be aliased could be > a vendor-specific configuration and should be encoded as such. That > kind of separation of concerns has not happened at all. > > It should also be noted that the patch describes itself as > incomplete. No attempt at completing it seems to have been made thus > far. It is a proof of concept patch, so I'm not surprised it doesn't address this. However, I suspect people won't feel motivated to address issues if the dpkg maintainer(s) just says "it's totally broken". Given the history of multi-arch patches, this seems to lead to a quite un- enjoyable process. > In > principle, the technical merits seem solvable to me, but the total > failure on the process level leaves me wish for a revert. If you want to turn back the wheel a few years and restart this discussion again, please open a tech ctte bug now or file a GR. Please also engage with upstream projects that do no longer want to support split-/usr to maintain the support there. Ideally also establish something to make sure we don't miss hardcoded paths that only work on usrmerged systems (e.g., udev rules, not always called code paths in programs, ...). If you don't want that solution, please don't suggest it repeatedly: it's non-motivating to spend any further time. > The communication is clearly > failing on both sides, which is why we're here at the ctte again. Sure, it fails. And the tech-ctte process is painful again too: we need at least a month-long discussion even about just the current postinst warning even though I've seen not many people aggreeing with having it: at least one ctte member objected to a proposal to vote on this sooner. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Thu, 2022-03-24 at 09:12 +0100, Ansgar wrote: > On Tue, 2022-03-15 at 15:14 -0700, Josh Triplett wrote: > > This escalation seems in direct contradiction to the tech-ctte > > decision in 994388. > > It already confuses users, for example: It was pointed out in #-devel that there are bugs in `dpkg-fsys- usrunmess` that might make systems no longer boot, at least #1008316 and #1008478. As I suspect more people will try running it due to the newly introduced warning by dpkg's postinst script, I feel this will needlessly break user systems. While we can't avoid all such bugs in programs to move from/to merged-/usr, I believe we should not recommend users to do such conversions needlessly (given we have decided to move to merged-/usr previously). It feels quite unprofessional for the dpkg maintainer to cause this avoidable breakage of user systems due to his disagreement with the project's decision. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote: > On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote: > > Maybe it should be changed into a warning that non-merged-/usr > > systems > > will not be supported in the future. The `dpkg-fsys-usrunmess` > > program > > should probably also include a warning that it will convert the > > system > > into a state no longer supported by Debian in the future. > > What is supported is a bit subjective I fear. No, Helmut, it is not. We had that discussion often enough and in this bug report you will find the following: +--- | There are currently Debian 11 installations with both the merged-/usr | and non-merged-/usr filesystem layouts. All of these installations | should successfully upgrade via normal upgrade paths to a merged-/usr | Debian 12. Only after the release of Debian 12 can packages assume | that all installations will be merged-/usr. +--- I'm not motivated to pretend the last years did not happen. Feel free to start a GR to override the tech ctte if you think that is necessary. > > Either way, given related questions were already before the tech > > ctte > > several times it would be nice if this could be decided quickly to > > avoid this becoming yet another energy drain (we had several > > sufficiently long enough threads about this topic already). > > As much as I'd like to see this resolved quickly, I fear it is > blocked on the lack of patches supporting merged-/usr. Given all new installations have been merged-/usr for years, it seems to work sufficiently well for real-world use. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Tue, 2022-03-15 at 15:14 -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 > <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>. > > This escalation seems in direct contradiction to the tech-ctte > decision in 994388. It already confuses users, for example: - https://old.reddit.com/r/debian/comments/tew0w7/whats_going_on_with_dpkg_and_usrmerge/ - https://lwn.net/Articles/889026/ Maybe it should be changed into a warning that non-merged-/usr systems will not be supported in the future. The `dpkg-fsys-usrunmess` program should probably also include a warning that it will convert the system into a state no longer supported by Debian in the future. Either way, given related questions were already before the tech ctte several times it would be nice if this could be decided quickly to avoid this becoming yet another energy drain (we had several sufficiently long enough threads about this topic already). Ansgar
Bug#994275: Reverting breaking changes in debianutils
On Fri, 2021-09-24 at 09:26 +0300, Adrian Bunk wrote: > In my opinion, an amicable middle-ground proposal would be that the > debianutils maintainer completely removes "which" from debianutils, > and assuming the sysvinit-utils maintainers agree, that they adopt > both the existing "which" and (at least temporarily) "tempfile". There is an open bug asking for sysvinit-utils to no longer be essential[1]. With that in mind one should probably not move new stuff to it to keep it in the essential set. (This is no argument for/against `which` and/or `tempfile` to be considered essential.) Ansgar [1]: https://bugs.debian.org/851747
Bug#978636: move to merged-usr-only?
On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote: > 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. I fear we are drifting away from just deciding to move to merged-/usr to implementation details, but I originally[1] suggested to wait one release between making merged-/usr mandatory (could happen in bookworm) and moving installation paths in packages (could happen in trixie). This seems to avoid several problems: - partial upgrades to bookworm or backported packages from bookworm to bullseye and from trixie to bookworm should still just work (backports from then-testing trixie to then-oldstable bullseye, that is over two releases, would need to take a bit more care) - we need to touch packages for the move only once - compat symlinks have various problems (cf. references to essential packages[2] and OpenSuSE[3]). Ansgar [1]: https://lists.debian.org/debian-devel/2020/11/msg00232.html [2]: https://lists.debian.org/debian-ctte/2021/01/msg00041.html [3]: https://lists.debian.org/debian-ctte/2021/01/msg00037.html
Bug#978636: move to merged-usr-only?
Hi, Simon McVittie writes: > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? > > Some developers seem to be using "merged /usr" to refer to multiple > concrete layouts: > > 1. an arrangement where all regular files that have traditionally been >in /bin, /sbin, /lib and /lib64 are physically located in /usr, >with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib, >/lib64 -> usr/lib64 Having filed this bug, I only consider this "merged-/usr". Symlink farms (/bin/sh -> /usr/bin/sh) are a different layout and should be given a different name. With that said, I consider the symlink farms also unrealistic for use as an intermediate state in the transition. This was tried by another distribution[1] and it didn't work out; nobody said why Debian wouldn't end up in the same unfortunate situation from which it is even harder to migrate to merged-/usr. >From my point of view the only realistic proposal for migration so far is usrmerge, possibly with modifications. We might also want to be extra careful and use non-merged-/usr on buildds for one more release and only move them to merged-/usr for the release after merged-/usr was made mandatory (so any packages installed as part of the upgrade to the release that makes merged-/usr mandatory are still built on systems with non-merged-/usr for the reasons we do so currently). But I consider these implementations details; it's only useful to discuss them when we know where we are going and most (or hopefully all) detail questions probably don't need the technical committee either. Regards, Ansgar [1]: https://en.opensuse.org/openSUSE:Usr_merge
Bug#978636: move to merged-usr-only?
Package: tech-ctte X-Debbugs-Cc: debian-de...@lists.debian.org Hi, as suggested in [1], I would like to see Debian to move to support only the merged-usr filesystem layout. This would simplfy things for the future and also address the problem with installing files under aliased trees that dpkg has to do for both variants to be supported. merged-usr has been the default for new installations since the last release and (as far as I am aware) no world-breaking bugs have happened since; some environments such as buildd chroots still do not use merged-usr. I would like to ask the technical committee to decide whether we want to move to merged-usr-only. It seems to be a case of overlapping jurisdiction (6.1.2 in the constitution). I'm not asking the committee to decide on a concrete technical implementation for this. Obviously we would need to also implement a migration path for legacy installations for a move to merged-usr-only to be implemented. This also isn't relevant for Debian 11 (bullseye), but I would like to have enough time in the Debian 12 (bookworm) cycle. Ansgar [1]: https://lists.debian.org/debian-devel/2020/11/#00232 continued in December: https://lists.debian.org/debian-devel/2020/12/#00386
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote: Not is it straightforwardly clear that "alternative init systems" should in fact be interpreted to mean "alternative init systems (but not sysvinit)". The GR text mostly seems to talk about *exploring* alternatives; continuing to maintain a 30 year old system doesn't really seem explorative work to me? Even retiring sysvinit support completely seems fine with the GR's text. Besides preserving sysvinit in its current state (arguably not exploration), not much else seems to happen with regard to alternatives to systemd as far as I am aware? For exploration, much less support is needed: to install systemd-sysv you had to fight with dpkg to uninstall / keep away an essential package (sysvinit) for several years or choose alternative routes (e.g. specify init= on the kernel command-line); you might have needed to write .service units yourself to start services using systemd's native facilities instead of a (limited, but well-working) compatibility layer. I still have some custom .service units for packages that don't ship one themselves. Arguably having to create "fake" packages using `equivs` or similar tools to satisfy dependencies one would like to force to be avoided would be comparable to having to remove essential packages? Not having all packages ship a sysvinit script must also be more or less expected: we have 250+ packages shipping .service files, but no sysvinit scripts in current testing. I already filtered out any packages shipping DBus .service files and some packages part of the systemd/sysvinit implementation itself for this, but there are some other false postives like .timer units with their associated .service unit that have equivalent cronjobs (though some might miss a cronjob as well). For comparison: 980 packages in total have any .service system units and 1057 have a sysvinit script (excluding the packages part of systemd/sysvinit itself.) In addition some package use other systemd-provided facilities that elogind conflicts with, e.g., systemd-tmpfiles; or systemd-hostnamed here for NM (AFAIU). As you already said you would like the technical committee to rule that similar changes should not be blocked by maintainer of other packages and already said you have some packages in mind, I think it would be interesting to know which ones you are talking about. Would maintainers have to accept patches stopping use of systemd-tmpfiles, systemd-hostnamed, ...? Ansgar
Bug#932795: How to handle FTBFS bugs in release architectures
Hi, as I'm not sure everyone is aware of what the problem with p4est was, I decided to write a short summary: - Summary -- - p4est uses MPI, a standard for parallel applications running on single machines up to clusters with 100 000+ cores. For MPI applications, it is usually a configuration error (resulting in degraded performance) to try to use more cores than are available. To avoid this, Debian's current default MPI implementation, OpenMPI, by default gives an error when trying to do so: `mpirun -np 64 echo Blubb` will give an error when less than 64 cores are available. One can tell OpenMPI to allow this as was done in p4est 2.2-1 by setting an environment variable when running the tests[1]. This is the same other programs using MPI do to run tests during builds in Debian; a similar environment variable needs to be set to not give an error when rsh/ssh is not available in $PATH. [1]: https://salsa.debian.org/science-team/p4est/commit/8803bea251517354c4cbe737e018fdf73cb27278 - For this particular class of bugs (MPI error during build due to oversubscription), I don't think there is any disagreement that these are bugs. They have been fixed in various Debian packages by setting the environment variable mentioned above. - The only disagreement here is about the severity of the bug report. Santiago Vila (submitter) wants them to be release-critical; Adrian Bunk disagrees as he considers single-core build environments to be so rare that a build failure in such an environment should not be release-critical (just as build failures due to lack of RAM, disk space in the same environment). - (The maintainers of p4est have said nothing about the severity dispute; neither Santiago nor Adrian maintain the package.) - Opinion -- - As far as I understood, the main argument for making build failures on single-core systems release critical is that "we are currently forcing users to spend extra money if they want *assurance* that all the packages [...] will build"[2]. [2]: https://lists.debian.org/debian-ctte/2019/07/msg00024.html I do not think this is a good argument: from a quick search any environment that might give such an assurance will very likely already have more than a single core. (I assumed one wants 4+ GB RAM; it is hard to find single-core systems or VMs in the cloud with that.) The environment used by the submitter already fails such an assurance: 4% or ~1000+ source package already fail to build in it. It seems to me there is no large practical impact if 10-20 more packages fail to build in it due to single-core issues. (As far as I understand these issues are very rare; please correct me if this affects significantly more packages.) - Historically the upper bound for resource requirements for builds (RAM, disk space) has been whatever the current buildds offer. It seems unlikely we would get to lower boundaries as some packages usually barely build on the buildds; some already require work arounds (such as disabling debug information for some environments). Most packages are of course fine with less resources, but we are talking about requirements for *all* packages. - While we could make build failures on single-core systems release critical, I believe that this is not warranted as the practical implications of such build failures do not seem very high to me: one would just build them in an environment suitable for "large" packages. (Such bugs should of course still be fixed, but that doesn't require them to be release critical.) Ansgar
Bug#932795: Ethics of FTBFS bug reporting
Russ Allbery writes: > Ansgar writes: >> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember >> the suggestion that one might have to switch to 64-bit compilers even on >> 32-bit architectures in the future... So building packages would in >> general require a 64-bit kernel, multi-arch and 4+ GB RAM. [...] > I'm rather dubious that it makes sense to *require* multiple cores to > build a package for exactly the reason that Santiago gave: single-core VMs > are very common and a not-very-exotic environment in which someone may > reasonably want to make changes to a package and rebuild it. But maybe > I'm missing something that would make that restriction make sense. Well, the package that gave raise to this issue is this: The p4est software library enables the dynamic management of a collection of adaptive octrees, conveniently called a forest of octrees. p4est is designed to work in parallel and scale to hundreds of thousands of processor cores. I doubt many people from that application domain work with single-core systems. There are other interesting issues as well: I recently had problems with running a numerics library in a VM where the CPU supports AVX-2, but the VM instance did not. But the library used the CPU model to select its preferred implementation (which then used AVX-2 instructions)... Just like issues with single-CPU systems this is a bug, but not one with a high priority for me. Ansgar
Bug#932795: Ethics of FTBFS bug reporting
Adrian Bunk writes: > - An environment with at least 16 GB RAM is supported. > > Not sure about the exact number, but since many packages have > workarounds for gcc or ld running into the 4 GB address space > limit on i386 it is clear that several packages wouldn't build > in an amd64 vm with only 8 GB RAM. Aren't there even packages that will not build on i386 with a i386 kernel (non-PAE) as they require the full 4 GB address space to be buildable? Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember the suggestion that one might have to switch to 64-bit compilers even on 32-bit architectures in the future... So building packages would in general require a 64-bit kernel, multi-arch and 4+ GB RAM. Ansgar
Re: Thinking about Delegating Decisions about Policy
Bill Allombert writes:
> In my view it is detrimental for the policy proces for the Debian policy
> to include decisions made by the TC, because this leads to a situation
> where some policy text is frozen because the policy editors cannot change
> it without potentially overriding the TC.
Then the TC should (always) state explicitly that changing this using
normal processes is allowed.
The "Debian Maintainer" role was introduced via GR which also specified
implementation details ("DM-Upload-Allowed" in source packages, jetring
to be used to maintain the keyring on Alioth, ...). Quite a bit of
which has changed without a second GR as it was assumed that "The
initial policy for ... will be ..." meant the policies could be changed
via normal processes, usually by the responsible people agreeing on a
change.
So I think having parts of policy frozen can be avoided even when the TC
sets it; I even agree that it should be avoided.
Ansgar
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Johannes Schauer writes: > With how merged-/usr is getting deployed via debootstrap, we are placing more > of the instructions of how a Debian system is supposed to be setup *outside* > of > the packages themselves (and into debootstrap). It would make a cleaner design > if we could have all necessary definitions of how to create a Debian chroot > from scratch (on a Debian system) in the packages *themselves* instead of > requiring code around the packages that is doing some magic setup (usually > debootstrap). One could drop the magic setup if merged-/usr was mandatory: (1) have /bin -> /usr/bin symlinks shipped in base-files (2) have all packages install to /usr The additional complexity of having to setup symlinks outside the packaging system comes from supporting both merged and nonmerged setups. debootstrap or the usrmerge package implement some way to setup the symlink which would not be necessary if they were included in the packages; it would not be necessary if (1) was implemented (plus handling system upgrades from legacy installations). On merged-/usr systems, packages could just switch install location gradually; they would install to the same location anyway, no compat symlinks or maintainer script logic required. Ansgar
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Steve McIntyre writes: > There is a deeper worry about builds that may be done against the > "weak" background. Although buildd chroots are easily fixed up, > there's going to be a (small, but unknown) set of maintainers who > might be uploading binaries from merged systems. I think we're making > good progress on source-only uploads and building in clean chroots > etc., but... It's also likely not easy to pick up on "wrong" binary > packages built this way. That is not a new problem: maintainers can already upload packages that refer to binaries in /usr/local/bin when they have locally installed binaries and autodetection using $PATH is used? /usr/local/bin is usually before /usr/bin and /bin after all. dpkg could add a "not-built-in-a-clean-chroot" flag to detect those. Ansgar
Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune
Dear technical committee, it would be nice if #919951 would be dealt with in time to allow affected packages to migrate to testing before the freeze. FWIW it looks like whitedune was now binNMUed, but dune is still blocked by #919953. Ansgar writes: > I am tempted to suggest that this issue is dealt with by passing a > resolution reminding the submitter of 6.3.6 of the constitution and > suggesting a bit more constructive behavior in the future. This still looks like a good resolution to me. Ansgar
Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune
Ian Jackson writes: > Meanwhile there seems to have been no contact with the maintainers of > the C++ library which is the only hit on Wikipedia for > https://en.wikipedia.org/wiki/Dune_(software) Whitedune also has a Wikipedia entry: https://de.wikipedia.org/wiki/White_dune So they are probably also relevant by the "has a Wikipedia lemma" metric (which is not a good metric here anyway IMHO). > (Amazingly, this is still true at the time of writing even though > I referred to this fact in the debian-devel thread.) I would have hoped that package maintainers would be asked /before/ issues are escalated to the ctte referencing their packages as reasoning. Sadly this doesn't seem to be the case... > Please would the Technical Committee: > > * Declare that no-one is allowed the name /usr/bin/dune other than >the C++ library dune-common or its friends. > > * Declare that no-one is allowed the binary package name >/usr/bin/dune other than the C++ library dune-common >or its friends. > > * Declare that the ocaml build system should choose a new source >package name and use it henceforth. > > I am about to file an RC bug against the `dune' package, blocked by > this one. For the DUNE numerics side, I think a fair summary is: nobody minds OCaml using /usr/bin/dune; there was a minor concern that "dune" as a package name might be confusing (but Anil Madhavapeddy suggested that the package could possibly be named "libocaml-dune" or "ocaml-dune" in Debian). Outside of the technical parts: It is hard to avoid name collisions (unless you use random names); there are several other projects that are also named "dune". Or other well-known cases of name collisions (e.g. gentoo, git or chromium (the OpenGL implementation, game, and browser)). I think calling people who choose colliding or confusing names arrogant, ignorant, or such is not helpful at all. I wouldn't like to be associated with that and am quite unhappy that packages I maintain are dragged into Ian's fight here. As a random quote, I would like to end with: +--- | Earlier this year, we announced "DGit" or "Distributed Git," our | application-level replication system for Git. We got feedback that the | name "DGit" wasn’t very distinct and could cause confusion with the | Git project itself. +--- Just as a guideline for the other 3+ projects that might have come up with that name ;-) I am tempted to suggest that this issue is dealt with by passing a resolution reminding the submitter of 6.3.6 of the constitution and suggesting a bit more constructive behavior in the future. Ansgar
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Ian Jackson writes: > This is especially the case since none of the other possible > candidates for how to set this distribution-wide policy are useable: > the Policy editors have decided that Policy should lag implementation > rather than lead it; debian-devel didn't work; and there is no other > forum or body with sufficient breadth. I was asked for a discussion on -devel@ by the d-i maintainers before I filed the bug report to enable this feature. It is mentioned in the initial bug report too[1]. [1] https://bugs.debian.org/839046#5 While you claimed[2] there were negative responses in that particular thread, there weren't any as far as I could see[3]. Sadly you didn't bother replying. [2] https://bugs.debian.org/839046#94 [3] https://bugs.debian.org/839046#112 You didn't provide any concrete examples of what would be broken back then, even when explicitly asked[4]. [4] https://bugs.debian.org/839046#99 The same pattern seems to continue as you claimed that the "design is broken" in the request to the ctte[5], but do not want to provide reasoning why. Or make claims that there wasn't enough consultation (even though there was so much discussion that LWN wrote at least one article about the discussion on -evel@); as usual you do not follow-up on requests to clarify any of this. [5] https://bugs.debian.org/914897#208 (Not that having consensus would mean anything given how you handle that in [6]...) [6] https://bugs.debian.org/850967#42 I'm sorry, but I feel that you are not interested in discussions around technical problems, but instead (once again) fight for some other reason (just like in the DUNE bug IMHO)... The (solvable and minor) technical problem that was reported half a year after the default was switched was just a convenient starting point to escalate the issue; it isn't even mentioned any more: instead you now switch to "social costs". Here I find it unfair to pressure people into reverting the change /now/ as the freeze comes closer as such reasons would have applied the years before November as well, and certainly since the default was switched again in June last year. Ansgar
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
Hi, Hideki Yamane writes: > On Sun, 2 Dec 2018 15:15:21 + > Simon McVittie wrote: >> > - What is the problem? (broken build for which packages? Just R?) >> >> The problem we're aware of is: >> >> Some packages auto-detect the absolute path to an executable (for example >> bash or perl) and hard-code it into their output (for example the #! line >> of the bash scripts in quilt). > > Can we check and track this behavior in our packages? The Reproducible Builds project was so kind to help and now runs one build in a non-merged-/usr and a second build in a merged-/usr environment. Packages that hardcode the path to utilities, but would pick up the wrong one in a merged-/usr environment will result in a difference between the two builds and can thus be found. See [1] for an overview of issues found this way; as the entire archive was already rebuilt in this setup, there shouldn't be many more issues of this type that we don't know about[2]. Not all of these differences even cause issues as in a few packages the utility with the hardcoded path is not even used at all. Bug reports were already submitted for over half the packages, often including a simple patch (usually something like adding BASH=/bin/bash to dh_auto_configure). So we look to be on a good track to address the remaining issues. I don't think that the debootstrap default has to be reverted temporarily again to deal with this: there are only very few packages causing problems and these should have a patch soon. In addition one has to actually built one of the very few packages in a merged-/usr environment and then install them in a non-merged-/usr environment to actually trigger the problem and debootstrap already defaults to non-merged-usr for buildd chroots for now. Ansgar [1] https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html [2] https://bugs.debian.org/914897#81
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote: >> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly >> confident that for more than 0.3% of the archive something can go wrong >> when building in non-clean environments. > > Your figure of ~80 packages counts only packages which went through a > reproducible-builds rebuild. So only all? > We later learned only a part of the archive got rebuilt since the bad > debootstrap backport. Yes, some packages were not yet rebuilt in testing, but having them rebuilt in unstable is enough. >> We had the discussion (usrmerge as default) already quite some time >> ago. Why start again at zero? As a random reference, the D-I Stretch >> RC 1 release announcement explicitly stated: >> >> +--- >> | * The switch to merged-/usr as the default setting for debootstrap >> |was reverted since it uncovered a number of important issues which >> |might not be all fixed in time for stretch. This setting is >> |expected to come back as the default at the beginning of the next >> |release cycle. >> +--- >> >> And just that happened (except a bit later). > > Except that the change went live only on 2018-11-10, then waited until > buildds recreated their chroots, then until dinstall and mirror push... No, anyone using testing/unstable to setup a new build chroot since June should have gotten a merged-/usr chroot. That no issues were found earlier is probably related to there being not so many issues. (Fun fact: there are ~3k debootstrap installations on testing/unstable, compared to 6.2k on stable and 2k on oldstable according to popcon.) Anyway, buildds are not using merged-/usr, so there is no problem with them. > and the sky started falling immediately after that. Hmm, two packages or so were reported to be broken. That is a quite high standard for "sky falling". What would you call an upload that breaks more packages? The monthly apocalypse which we deal with just fine? >> You could have easily asked the tech-ctte back then (or even before) >> instead of waiting until shortly before the Buster freeze and after >> people invested more work. > > It was only shortly before the Buster freeze that we saw this change in > action! Had the switch get flipped sooner we'd have a chance to see the > results. By now, it's much too late to fix things before the freeze > (and I don't see how they could be fixed even had we two years of > time). You keep saying that it is too late to fix anything or that it is too much work, but why do you think so? I've looked at patching packages and how many packages need changes and it does not seem much work; indeed after a week about half of the packages already have a (usually trivial) patch. If you think it is too much work or too many things break, please at least give an estimate of what you are talking about... I feel like only one side is doing any research here. > By now, all we can do is damage control. Which can be a hasty force-merge > or a hasty revert. Unless you can somehow make dpkg-dev omniscient. If we keep merged-/usr as default then we can /recommend/ people to install usrmerge to switch to merged-/usr; reducing the difference between newly-installed and existing setups is a good idea IMHO. I think I filed a report for this two years ago. Maybe we should also mention somewhere that it might be useful to not switch build environments (yet). Ansgar
Bug#914897: debating the wrong thing
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrmerge program to convert systems with merged-/usr to
>> systems with unmerged-/usr.
>
> Currently merged-usr is broken because it can build packages which do
> not work on non-merged-usr systems.
In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
confident that for more than 0.3% of the archive something can go wrong
when building in non-clean environments.
> It would be quite wrong (both technically and socially) to react to
> this lack of foresight,
The reported problems are not really unexpected...
> lack of consultation,
It was discussed on -devel@ several times. I think LWN also reported
about merged-/usr developments in Debian more than once, it wasn't a
secret cabal development.
So where is the lack of consultation?
> and lack of testing, by pressing forward.
It has been tested for quite a while.
A helpful new test was recently added by the Reproducible Builds project
which allowed to identify most problematic packages.
What is technically and socially wrong is reverting a change after a
small issue was found which is already in the process of getting fixed
for most packages.
> When we have stopped generating more lossage, we can start to think
> about whether we want to transition to usrmerge as default, whether to
> make it mandatory, and if so how the transition should be handled, and
> on what timescale.
We had the discussion (usrmerge as default) already quite some time
ago. Why start again at zero? As a random reference, the D-I Stretch
RC 1 release announcement explicitly stated:
+---
| * The switch to merged-/usr as the default setting for debootstrap
|was reverted since it uncovered a number of important issues which
|might not be all fixed in time for stretch. This setting is
|expected to come back as the default at the beginning of the next
|release cycle.
+---
And just that happened (except a bit later).
You could have easily asked the tech-ctte back then (or even before)
instead of waiting until shortly before the Buster freeze and after
people invested more work.
Making it mandatory or not is an unrelated decision. That can easily
just come later.
> We need the space to discuss those options properly without being
> distracted by what is IMO currently a crisis in stretch-backports and
> buster.
There is no such crisis. There was also enough time to discuss this in
the last years or even since June (when it was enabled by default
again)...
Ansgar
Bug#914897: debating the wrong thing
"Alexander E. Patrakov" writes: > Ansgar Burchardt wrote: >> Making the feature default was discussed years ago which you are surely >> aware of. It's not mandatory. > > Unfortunately I have to disagree here. Merged /usr is already, > de-facto, mandatory for everyone who installs Debian Testing using the > official netinst CD. Yes, but the "make merged-/usr mandatory" refers only to require to merge /usr on upgrades; nobody has asked for there to be an installer option (and I don't think it would be useful). Ansgar
Bug#914897: debating the wrong thing
Adam Borowski writes: > On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote: > I believe the difference between those is less than between suboptions of 1 > and 3, but then, as an opponent of 2 as a whole I'm biased. > >> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr >> systems would no longer be supported. > > They'd be exactly as supported as they are today. Ie -- they'll continue to > work, Yes. > and continue to be useless for building packages without a clean > chroot. Oh? What makes you think so? You are free to correct my earlier estimate about the number of problems. So long I'll assume I'm not totally wrong. If I'm wrong by a factor of 3, then 99% of the packages will just build fine. And fixing any problem is in most cases straightforward. >> In this case someone would have to write a unusrmerge program to convert >> systems with merged-/usr to systems with unmerged-/usr. >> Such a program doesn't exist yet and is probably more complicated than >> usrmerge: for example how would it know that a /sbin/iptables -> >> /usr/sbin/iptables symlink would have to be created when unmerging the >> system? Moving files from /usr to / is also more likely to run out of >> disk space (if separate partitions are used for /usr and /). >> >> I'm not sure how long it would take to get this right and so agree that >> (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. > > unusrmerge would still be still far less work than continuing with 2. Why do you think so? Trivial patches for the remaining few packages seem easier. > Yet I don't understand your claim why 1 or 3a w/o usrmerge-in-buster > would cause any problems. In fact, they require no work at all (in > Buster's cycle) beyond an upload of debootstrap. Unless someone builds a package in an already existing install... If not being able to build packages in existing installations is not a problem, I'm even less sure what the problem with merged-/usr by default is supposed to be? Ansgar
Bug#914897: debating the wrong thing
Gunnar Wolf writes: > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]: >> (...) >> So, let's enumerate possible outcomes: >> >> 1. no usrmerge >> 1a. no moves at all (no effort needed!) >> 1b. moves via some dh_usrmove tool, until /bin is empty >> 2. supporting both merged-usr and unmerged-usr >> 3. mandatory usrmerge >> 3a. by Bullseye >> 3b. by Buster >> >> Unless the TC decides for 2., all this work will be a pure waste of yours >> and maintainers' time. > > ...One thing I fear here, that's also not being clearly debated AFAICT > (although the "urgency" of this report points in the right direction) > is that if the TC decides towards anything but 2 or 3b, we will have a > hard time reaching and following through the freeze targets proposed > by the Release Team. Which is something we don't want. I don't think this list is good as (2) doesn't say anything about the question asked originally (the default) and (3a) doesn't say anything about what happens for Buster. Currently implemented is (2) + default to merged-/usr for new installations. Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr systems would no longer be supported. In this case someone would have to write a unusrmerge program to convert systems with merged-/usr to systems with unmerged-/usr. Such a program doesn't exist yet and is probably more complicated than usrmerge: for example how would it know that a /sbin/iptables -> /usr/sbin/iptables symlink would have to be created when unmerging the system? Moving files from /usr to / is also more likely to run out of disk space (if separate partitions are used for /usr and /). I'm not sure how long it would take to get this right and so agree that (2) or (3b) or (3a-with-support-in-buster) are reasonable choices. >> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in >> 3a "for now"). With 3b you need some way to make sure existing systems are >> converted (also with 3a except for far more time for testing). > > I agree with your assessment. There are still too many mails I haven't > read, though, and I cannot commit my hypothetical vote so far, but I > think the sanest way will be to revert the change in debootstrap. So (2) with the default to non-merged-/usr or (3a)? I'm not sure why (2) should not default to merged-/usr though. Ansgar
Bug#914897: debating the wrong thing
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
> > do
> > this at all" years later.
>
> We were told it would be optional. Unfortunately it turns out that
> the design is broken and it cannot sensibly be made optional.
There is no indication of that. So I'll assume the design isn't
broken.
You aren't entitled to just claim that.
> Nor does a failure to review and object to your design of an optional
> feature mean that you are entitled to assume consent for making the
> feature default or mandatory.
Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.
> The problem comes when a niche optional feature, with wide-ranging
> implications, is suddenly promoted to the default, without proper
> consultation and without a proper transition plan.
It wasn't made "suddenly" the default.
Ansgar
Bug#914897: debating the wrong thing
Adam Borowski writes: > I see that we're debating the merits of merged-usr vs non-merged-usr, while > expending lots of effort and filing bugs (requiring further urgent action of > unrelated maintainers), for little gain. There is no "urgent action" required (unlike, say, for the last glibc update). If you don't want support for merged-/usr, could you please discuss this back in 2016 or before that? Also I feel a general discussion would probably just be too long-winded and touch too many unrelated issues; there is not even a terse list of claimed problems. It is very demotivating to have discussed and implemented something mostly years ago, for people then to come and complain "let's not do this at all" years later. Maybe we should also revisit Multi-Arch now that we know that `Multi-Arch: foreign` relations as implemented can result in non-booting systems... Or really revisit the init system question before people file bugs that require further urgent action for little gain (it's probably too late in the release cycle to push in elogind anyway). There is also the question if it is still worth to spend maintainer efforts to ship sysvinit scripts if this means we lose the advantages of declarative service files (which means far more work than merged-/usr changes)... We could also open a tech-ctte bug for secure boot before I spend any more time on it (there are still a few things). Luckily having this discussion delays me spending time on the remaining things I wanted to look at, so at least not more time is wasted. (Not that I currently have too much time for Debian anyway, and secure boot is quite a lot of work for something I don't need...) Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes: > The next debhelper change might choose to give / instead of /usr as a > target directory by default, moving hundreds of megabytes from /usr to / > over time. My question was about the distant future, and not the current > snapshot of things. If anything then /usr would be the prefix for all packages; nothing would be installed to /bin, /sbin or /lib. (And there is no /share or /local.) But this is obviously only possible if non-merged-/usr is not supported at all as that would mean shipping only /usr/bin/sh and no /bin/sh; the /bin -> /usr/bin symlink would then be required. Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes: > On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote: >> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit : >> > Will binaries move from /usr/bin to /bin? Or will binaries move from >> > /bin to /usr/bin? >> >> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking >> /bin/grep will make that binary end up in /usr/bin/grep; but the >> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep >> directly or /bin/grep through the symlink. > > And where will the binaries and up on an un-usrmerged system with a > dedicated /usr? in /usr, I hope? They won't move on a system that doesn't have merged-/usr. /bin/bash will stay in /bin/bash. If you switch to a merged-/usr (for example by installing usrmerge) then they will be moved to /usr. Ansgar
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what will happen when a package
> built on a usrmerged System will be installed on a non-usrmerged system?
>
> Will binaries move from /usr/bin to /bin? Or will binaries move from
> /bin to /usr/bin?
They will be installed in the place the package installs them. Note
that there are no /bin -> /usr/bin symlink in the staging area where the
package is built (i.e. debian/${package} or debian/tmp).
Packages have to continue shipping binaries in /bin unless we decide to
make merged-/usr mandatory and convert existing systems.
Ansgar
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
Ansgar Burchardt writes: > There were discussions about enabling this by default years ago, I > don't think minor issues should be a reason to delay this change. > > Note that it has been delayed for after the stretch release as there > were major issues back then (it was enabled by default for a short time > in stretch). It took >5 months for someone to find a problem this time > which is pretty good for any change. So, I went through all reproducible build failures in unstable without notes and added notes for differences caused by building in merged-/usr vs non-merged-/usr packages. Together with what other people tagged, about 60 problems were found. (The oldest rebuild result for unstable is 17 days old, the merged-/usr variation was deployed before that[1].) [1] https://bugs.debian.org/901473#43 There might be some more that as diffoscope had problems or the diff was too large for some packages (but I'll assume that in this case merged-/usr is not the only problem the package had). This should cover all packages that had no other problems and were reproducible before, that is about 80% of the archive. Assuming the rate is similar for packages which have other reproducible build problems, I would expect 60 / 80*20 = 15 more problems. I haven't looked at build failures, but I would expect these to be usually not caused by merged-/usr. So an estimated ~80 packages which might need adjustments for building correctly in both merged-/usr and non-merged-/usr. I guess less than for the average new release of GCC ;-) The problems are usually easy to fix by passing an explicit path the the package's configure script at build time; of course there might be some package where it is more complicated. Ansgar
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote: > Dear Hideki, dear src:debootstrap maintainers, > > tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by > default now, or are you OK letting the TC decide on this subject? There were discussions about enabling this by default years ago, I don't think minor issues should be a reason to delay this change. Note that it has been delayed for after the stretch release as there were major issues back then (it was enabled by default for a short time in stretch). It took >5 months for someone to find a problem this time which is pretty good for any change. Ansgar
Bug#914897: affects private debs too
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not convinced this is a good idea: it seems like it causes as many
> problems as it solves. It's effectively a gradual implementation of
> making merged /usr mandatory, with a lot of moving parts (places where
> it could go wrong) and a lot of packages and maintainers needing to be
> involved, but without the simpler end result of *actually* merging /usr.
Well, people don't like the simpler solution that someone else
proposed...
> We've been migrating from non-multiarch to multiarch for more than 5
> years and have still not got there, so I'm not confident that ad-hoc
> migration from unmerged to merged /usr would go any quicker.
Migrating /{s,}bin involves far fewer packages (only ~200 binary
packages). There is still /lib though.
> It can also cause the same failure modes with hard-coded executable paths
> as merged /usr. Let's suppose we migrated grep from /bin to /usr/bin in
> the way you suggest during the Debian 11 release cycle. If a package that
> hard-codes the compile-time grep path (again, consider gzip, #914907)
> is built with the new grep, it won't work correctly with the old grep
> during a partial upgrade from Debian 10 to 11; but I don't see how it
> would pick up a versioned Depends on the new grep without manual action
> from the dependent package's maintainer, which isn't going to scale well.
You will always have this problem with partial upgrades unless *every*
package depends on a package that would ensure that the system has all
binaries previously in /bin also in /usr/bin.
In particular, if we want to treat this as a (release critical) bug,
iptables or any other package ever moving from /bin to /usr/bin (or the
other way) will always be buggy, regardless of any merged-/usr. Same
for any binary ever moving between .../bin and .../sbin.
Ansgar
Bug#914897: affects private debs too
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping any packages that
>> > > aren't built on buildds.
>> >
>> > It would be quite a radical departure for Debian to no longer support
>> > "I built this package for my mate to install on their computer".
>>
>> For the case of locally built binaries, bringing any problem
>> that usrmerge would hit to the light would be preferable.
>
> Any checks you can do may test only packages that reached the Debian
> archive. We can discipline DDs, be it by requiring source-only, or by
> catching misbuilt packages, but we can't do anything for local packages.
>
> And these in a good part are not based on Debian sources.
>
> I for one use a .deb package to distribute my .bashrc to machines under my
> control. Joe from a derivative named Debuntituan provides an
> uber-proprietary-drivers package to his users. Any PPA. A company-wide
> repo. Etc, etc.
Debian is not responsible how third parties build their packages. We
don't even exclude /usr/local/bin from PATH when building packages...
(If you care about distributions not doing the same as Debian, one would
need to patch every package to build & work on both merged-/usr and
non-merged-/usr systems no matter what Debian does...)
> Thus: sorry but there is no way we can possibly support usrmerged and
> non-usrmerged systems at the same time. Usrmerge is not viable without a
> flag day.
Oh, it's possible. It makes life a bit harder than a flag day or clear
commitment to one setup, but so does supporting multiple init systems
(so the advantages of, for example, easier maintenance by having
declarative definitions is lost).
Regardless of debootstrap defaults or flag days, we could also consider
moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
/{s,}bin; this does not need a flag day. That is useful either way as:
a) some people will use /usr/bin/${x} instead of /bin/${x} anyway (they
don't have to come from Debian), and b) it would also make supporting
merged-/usr and non-merged-/usr simpler as the programs would always be
available in both locations.
Some packages such as iptables have already done this ad-hoc.
I'm toying around with ideas for a dh_usrmove tool which would allow to
easily add this to existing packages. That would also allow to drop it
later in one go should one in the far future require the /bin ->
/usr/bin symlink.
Ansgar
Bug#877024: Modemmanager probing of unknown Devices
Sam Hartman writes: > Also, as may be obvious from my previous post today, I was shaken by > some of the meta issues here. I am much more focused at the moment on > thinking about the TC process and our community than I am about this issue. If the ctte believes that escalating an issue to the ctte after not getting a reply from the maintainer in less than three days (time between [1] and [2]) is the way to go, I wouldn't be that motivated to deal with the ctte as a maintainer either. Also note that the bug has been inactive for over two years prior. (Well, on the plus side the package was just hijacked because rules don't apply to some people... That's a step forward.) Ansgar [1] https://bugs.debian.org/683839#77 [2] https://bugs.debian.org/877024
Bug#877024: modemmanager should ask before messing with serial ports
"Keith Packard" writes: > 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? It's not useless. At least not when using UMTS via USB dongles which I would guess more people use than ham radio. (Some of these USB dongles also emulate network cards and provide a DHCP server instead IIRC.) Ansgar
Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts
Philip Hands writes: > I stumbled across 'proot' while looking into the background for this, > which seems to be able to provide the effect of a bind mount without > needing root privilege, and would presumably deal with Ian's original > problem quite nicely. If you enable unprivileged user namespaces (the upstream kernel default; disabled by a Debian patch if I remember correctly), you can just use `unshare` and `mount --bind` on Linux: # echo 1 > /proc/sys/kernel/unprivileged_userns_clone $ unshare -r -m /bin/sh -c 'mount --bind /usr/bin/gpg /usr/bin/true; /usr/bin/true --version' gpg (GnuPG) 2.1.17 [...] Ansgar
Bug#835507: Please clarify that sysvinit support decision is not going to expire
On Fri, 2016-08-26 at 12:38 -0400, Sam Hartman wrote: > "Ansgar" == Ansgar Burchardt writes: > > Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote: > >> I think we want to reaffirm that policy section 9.3.2 and > section > Ansgar> 9.3.3 > >> represent current policy for init scripts, quoting > particularly > >> the following text from section 9.3.2: Packages that > >> include daemons for system services should place > Ansgar> scripts > >> in `/etc/init.d' to start or stop services at boot time > or > Ansgar> during a > >> change of runlevel. > > Ansgar> Does this really represent current policy? > > Ansgar> As far as I can tell Policy still assumes that sysvinit > is > Ansgar> the default init system and everything else is an > "alternate > Ansgar> init system" (9.11). > > There are many problems with regard to policy and init systems. I > believe that 9.3.2 on init scripts and 9.3.3 on update-rc.d are still > our current policy and still solid. I don't think so. There is the larger issue that 9.3 only describes init.d scripts, but doesn't mention the current default init system at all. But even for just describing those init.d scripts, it looks fairly outdated: Policy 9.3.3 looks really outdated: it talks about sequence numbers and one should ask on d-devel@ to choose the right one; it also says that update-rc.d will start services in runlevels 2-5 and stop them in 0,1,6 by default. However the default runlevels and sequence numbers are taken from the (required) LSB comments (directly or indirectly). These special comments are not mentioned anywhere. How invoke-rc.d is invoked is also slightly outdated (the `which invoke-rc.d` part), although there is a bug against Policy to drop that bit. 9.3.2 suggests that editing the init script is neccessary to disable a service without de-installing it: they are configuration files "to disable a service without de-installing the package". That is a bad example. The `status` and `force-stop` options are not mentioned anywhere (invoke-rc.d mentions them). Though this is a minor issue. Having `try-restart` (from LSB) would also be nice... It would also be nice if "behave sensibly" would be better defined (for example LSB has standard exit codes). 9.4 also looks outdated. The functions in /lib/lsb/init-functions should be used if consistent output is desired (as far as I know it defaults to a different look for the messages, see /lib/lsb/init- functions.d/20-left-info-blocks). Init scripts should also really use /lib/lsb/init-functions which makes supporting alternatives easier (take for example /lib/lsb/init-functions.d/40-systemd). Ansgar
Bug#835507: Please clarify that sysvinit support decision is not going to expire
On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote: > I think we want to reaffirm that policy section 9.3.2 and section 9.3.3 > represent current policy for init scripts, quoting particularly the > following text from section 9.3.2: > > Packages that include daemons for system services should place scripts > in `/etc/init.d' to start or stop services at boot time or during a > change of runlevel. Does this really represent current policy? As far as I can tell Policy still assumes that sysvinit is the default init system and everything else is an "alternate init system" (9.11). I don't think Policy in its current form should be reaffirmed, but should be updated to the current time instead. It should certainly reflect that we changed the default init system some time ago (note that Policy doesn't mention systemd anywhere). (Related to that, Policy currently requires *all* packages to ship sysvinit scripts that integrate with any alternative init system which I am fairly sure also isn't current policy...) Ansgar
Bug#830978: Browserified javascript and DFSG 2
On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote: > Or are you asking us to potentially overrule the ftpmasters inclusion > of libjs-handlebars? Or potentially overrule the release managers > determination of whether this particular bug is RC or not? [...] > I'd certainly be more comfortable if the ftpmasters and release > managers would weigh in here. On the concrete case of libjs-handlebars: the JS files we distribute seem to be generated by a parser-generator and thus certainly shouldn't qualify as source. I filed a seperate bug for this to keep it apart from the browserification issue, see [1]. [1] https://bugs.debian.org/830986 The ftp team can only catch shipping generated source by chance as we mostly just look at license headers. Avoiding such issues by using what upstream considers "source" already counts as a good reason to me. For the general case, I haven't yet looked into what "browserified" means exactly, but from skimming over the discussion on -devel@ it sounded like it was a glorified "cat"? In that case shouldn't one be able to easily use "cat" instead of "grunt" to build the package from the files upstream considers source? If it is more than "cat", some more information would be helpful. Ansgar
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie
On 11/28/2014 03:24 PM, Thorsten Glaser wrote: > On Fri, 28 Nov 2014, Ansgar Burchardt wrote: >> No, the ctte did not say that. We had a flamewar about that >> interpretation before. > > That was almost word by word from > https://lists.debian.org/debian-devel-announce/2014/11/msg0.html See [1] and [2] and possibly other places. Ansgar [1] https://lists.debian.org/debian-ctte/2014/11/msg00046.html [2] https://lists.debian.org/debian-ctte/2014/11/msg00049.html -- 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/547886a1.6090...@debian.org
Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie
On 11/28/2014 03:16 PM, Thorsten Glaser wrote: > On Fri, 28 Nov 2014, Marco d'Itri wrote: >> I disagree: upgrades should get the default init system unless the >> system administrator chooses otherwise. > > I disagree with you, and so does CTTE, this time: they said > that existing installations should retain their init system > – which goes along with “upgrades should not change the sy‐ > sytem state” generall – as much as possible. No, the ctte did not say that. We had a flamewar about that interpretation before. Ansgar -- 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/5478853d.3010...@debian.org
Bug#762194: Alternative proposal for init switch on upgrades.
Hi Svante, Svante Signell writes: > Has the proposed (pre-)depends ordering on init been tested and the > results known? You might want to read https://bugs.debian.org/762194#142, but the obligation for tests is really on the side of the people who want this change (IMO). Ansgar -- 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/8761e3nioo@deep-thought.43-1.org
Bug#762194: a technical proposal
Hi, Adam Borowski writes: > As Ansgar requests technical solutions, here's one: > > just like systemd-shim|systemd-sysv, switch the "init" package from > Pre-Depends: systemd-sysv | sysvinit-core | upstart > to > Pre-Depends: sysvinit-core | systemd-sysv | upstart >From a simple test this seems to change what debootstrap installs in some configurations (namely at least with --variant=minbase). Ansgar -- 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/87a93jyqzt@deep-thought.43-1.org
Bug#765803: Bug#762194: On automatic init system switching on upgrade
Hi, [ Replying to the bug. ] On 11/20/2014 06:27 PM, Don Armstrong wrote: > On Thu, 20 Nov 2014, Ansgar Burchardt wrote: >> Don Armstrong writes: >>> Speaking personally, without specific patches which have been discussed >>> with the maintainers of the init package and well tested, I'm unlikely >>> to vote any resolution on this issue above FD. >> >> Does this include the "no change is required" option? > > I don't think we have such an option even proposed. [Or even, any > options.] I'd probably be OK with an option which punted back to > maintainers to figure things out in the absence of real options. That's > technically no different than FD, but maybe effectively different. Past decisions to not overrule maintainers did not end with "further discussion". So I suggest a The technical committee declines to override the init system maintainers on the question of switching init systems on an upgrade to Jessie. option. (Note: I say init system maintainers as both sysvinit and the new init meta package are involved.) >> I would prefer if we did not end in perpetual further discussion until >> the freeze is over. > > I don't think using CTTE powers to try to prejudge something like this > for all un-proposed options is acceptable. Further discussion may be > annoying, but even if the CTTE were to decide, we'd still be discussing. Hmm? I don't think this is different from past issues that ended with declining to overrule people. My main point is that it would be nice to have this issue resolved soon given that Jessie is already frozen. And given there was no proposal how to implement the no-switch option to even discuss, I suggest the simple no-override solution from above. Ansgar -- 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/546e32e9.2070...@debian.org
Bug#765803: Bug#762194: On automatic init system switching on upgrade
Hi, Don Armstrong writes: > Speaking personally, without specific patches which have been discussed > with the maintainers of the init package and well tested, I'm unlikely > to vote any resolution on this issue above FD. Does this include the "no change is required" option? I would prefer if we did not end in perpetual further discussion until the freeze is over. Ansgar -- 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/87vbmas2w0@deep-thought.43-1.org
Bug#762194: On automatic init system switching on upgrade
Hi, I would like to see an end to open questions on systemd in Jessie. So, given that the GR is over and no technical proposals for not switching init systems on upgrade to Jessie have been made, is it possible to draw a conclusion to this issue now? I'm not sure there is much to gain from waiting longer... Ansgar -- 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/546c9240.8010...@debian.org
Bug#765803: Status of prompting / notification on upgrade for init system switch?
Hi Ian, On 10/21/2014 05:44 PM, Ian Jackson wrote: > I think the principle, of whether this switch should be made > automatic, ought to be addressed separately, and should be regarded as > a question of overlapping jurisdictions. We can't have different > maintainers fighting over init on users' systems by publishing > packages with dependencies which result in their preferred setup. What gives you the impression that different maintainers fight over providing init? I have not seen that happening. Ansgar -- 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/54468897.2080...@43-1.org
Bug#746578: More systemd fallout :-/
Ian Jackson writes: > As I understand it from reading the threads in the bug and on > debian-devel, the effect of this would be: [...] > * squeeze->jessie upgrades which are not already using systemd would > not be switched silently to systemd but would use systemd-shim > instead. That's wrong. [...] > My starting point is the following principle: > > * Users should not be switched automatically when upgrading. [...] > Having settled on the above principle, I think it follows that the > dependency ought to be changed. Except that we have not settled on that principle. So using it as a reason for other changes is not a very convincing argument. Ansgar -- 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/87zjdwj63q@marvin.43-1.org
Bug#744246: Processed: build profiles not yet supported by debian infrastructure
On 08/19/2014 14:27, Ian Jackson wrote: > Helmut Grohne : >> I ask you to find a way that enables uploading packages that make use of >> build profiles[1] to the experimental archive as soon as possible. The >> need for build profiles is already known for years (#661538), but it was >> hard to agree on a syntax which finally happened when dpkg 1.17.2 was >> uploaded to sid in December 2013. >> >> Currently uploading Build-Profile enabled packages fails, because such >> packages are rejected by dak. The immediate problem was summarized in >> this bug report: > ... >> Since filing that bug Johannes Schauer and myself talked to various >> teams to address this issue ultimately leading to no progress. >> >> * FTP indicated that they can work with whatever DSA installs. Using a >>non-packaged copy of python-apt from jessie was considered too much >>maintenance burden. I think we only talked on IRC, but we do not want to use a version of python-apt that does not come as a package from the archive and that we would have to maintain ourselves. I'm also at least unhappy if we introduced packages in the archive that cannot be processed with tools in stable (at least packages in unstable that might go into testing). >> * SRM deemed our patches too invasive. Thread starts at: >>https://lists.debian.org/debian-dpkg/2014/04/msg00034.html I think there were miscommunications... see also [1]. I don't think there has been a conclusion so far. [1] <https://lists.debian.org/20140725124517.ga17...@simplex.0x539.de> >> While each team's members were constructive at all times and their >> reasons are reasonable, the result is that build profiles do not work >> now. >> >> Given the above, I ask CTTE to find a constructive way allows uploading >> Build-Profile enabled packages to experimental (or even sid). > > Concretely, I think you are asking the committee to overrule one of > the following decisions: > > - ftpmaster's decision against using a non-packaged python-apt > - DSA's decision only to use stable or stable-backports > - SRM's decision not to accept your patches > - backports's decision not to accept your patches > > Is that right ? I don't think that is a valid option[2]. However, the ctte can of course offer advice. [2] <https://lists.debian.org/debian-devel/2014/06/msg00597.html> Ansgar -- 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/53f34900.2050...@debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Hi, Ian Jackson writes: > Can we stop the general commentary on Daniel Baumann's performance as > maintainer ? I don't think it's helpful or relevant to the discussion > about tftp-hpa and upstart. Is there still anything left to discuss on tftp-hpa/upstart or could this issue be closed? The last upload restored support for upstart[1]. [1] <http://packages.qa.debian.org/t/tftp-hpa/news/20140504T133456Z.html> Ansgar -- 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/87fvkmhe69@deep-thought.43-1.org
Bug#741573: Two menu systems
Hi, On 04/10/2014 13:48, Ian Jackson wrote: > That comes directly from its goal > of being easily consumable by a very wide range of window managers. The number of consumers (window manager, menu applets, desktop environments) is much smaller than the number of providers (in theory every application). Shouldn't a menu format be designed to be easy to use for the *larger* group of application providers? Having a goal to be easy to use on the window manager side and being less friendly[1] to the larger group seems to be the wrong design... More so if you take into account that application maintainers aren't really interested in menus, but people implementing menu systems are and have to know all the details. Ansgar [1] This might include maintainers having to convert icons at package build time and so on. -- 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/53468a49.30...@debian.org
Bug#727708: init system coupling etc.
Hi,
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
>> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
>> plans to depend on logind...
>
> logind is a red herring because AIUI we already have a technical
> solution to that. The problem is other things that might be in the
> pipeline.
But even the suggested (and not yet existing) solution is very likely
not a long-term solution given Canonical switches to systemd[1]. It
might still work for Jessie, but I expect it to be abandoned later (and
do we really want to use it for Jessie in this case?).
I wouldn't expect someone else to take up maintaince either: this hasn't
happened for ConsoleKit after all. It is probably even less likely to
happen here as the suggested solution involves using parts of systemd
and people vehemently opposed to it are unlikely to work on it.
Ansgar
[1] <http://www.markshuttleworth.com/archives/1316>
--
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/87zjltisp0@deep-thought.43-1.org
Bug#727708: init system coupling etc.
Ian Jackson writes: > Firstly, I think the scenario where the required integration work is > not done is unlikely. But in that scenario, we have two choices: > (a) Effectively, drop all init systems other than systemd > (b) Effectively, drop GNOME > > Of these, (b) is IMO clearly preferable. Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that plans to depend on logind... And it sounds like a really brillant idea to drop all of them to keep ChaosEsque Team happy with Debian. Ansgar -- 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/87bny9kddj@deep-thought.43-1.org
Bug#727708: Init system coupling call for votes
Hi, Andreas Barth writes: >> I hereby call for votes on the following resolution: >> >>The init system decision is limited to selecting a default >>initsystem for jessie. We expect that Debian will continue to >>support multiple init systems for the foreseeable future; we >>continue to welcome contributions of support for all init systems. >> >>Therefore, for jessie and later releases, we exercise our power to >>set technical policy (Constitution 6.1.1): >> >>Software outside of an init system's implementation may not require >>a specific init system to be pid 1, although degraded operation is >>tolerable. >> >>Maintainers are encouraged to accept technically sound patches >>to enable improved interoperation with various init systems. > > Voting in favour (i.e. Resolution, FD). I think it is a very bad idea to vote on a resolution proposed in anger, pretty much regardless of the contents. Ansgar -- 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/87a9dy12bb@deep-thought.43-1.org
Bug#727708: Both T and L are wrong, plea for something simpler
Hi, Steve Langasek writes: > Quite frankly, given that all members of the TC have by this point weighed > in with their preference on the "systemd vs. upstart" question and these > preferences can be tallied by hand, I don't think there should be any doubt > as to how the vote on that core question will go. So I don't think any > maintainers should feel blocked on this by the lack of a formal vote; I think it would be good for the project to already vote on the default init question. Having a first result would take a lot of pressure from the commitee and restore trust that you will be able to find a solution for the project (which I think a non-negligible number of people is losing right now). > I certainly don't think that the conclusion of the vote is the only blocker > for switching the default init system in jessie today, what I've seen > suggests that systemd integration is currently in a state that would cause > terrible regressions for many server users. I'm not sure of that (and would leave this to the systemd maintainers), but it would probably take at least a few weeks of preparation in any case. Ansgar -- 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/87siruttfp@deep-thought.43-1.org
Bug#727708: Call for votes on init system resolution
Hi, Russ Allbery writes: > Just to be very clear here, I do believe that we're deadlocked, even > though I expect the resolution process to be able to spit out a decision. > I don't mean deadlocked in the sense that Condorcet will fail, but rather > deadlock in the sense that the preferences above FD will result in a tie > and the question will be decided by casting vote. What would you think is the way forward in this case? A GR after all? Ansgar -- 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/87k3d6yctl@deep-thought.43-1.org
Bug#727708: Both T and L are wrong, plea for something simpler
Steve Langasek writes: > On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote: >> If you decide on the init system question first, you could just file a >> bug against debian-policy and things could go their usual way. >> Alternatively, the Policy maintainers could defer this decision to the >> technical committee under 6.1.3. > > The Policy maintainers are the maintainers of the policy document, they are > not "maintainers of the relevant software" in this context. No, but they are "maintainers of the relevant documentation", that is the Policy. And they don't just maintain the package, see the delegation text. So let me ask you again: do you choose to ignore the requirement that "maintainers of the relevent documentation" (that is the Policy editors) make decisions initially? Or do you think defining policies such as package dependencies do not fall within the Policy team delegation? Ansgar -- 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/87r47eyd80@deep-thought.43-1.org
Bug#727708: Both T and L are wrong, plea for something simpler
On 02/07/2014 17:01, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something
> simpler (was: Re: Call for votes on init system resolution)"):
>> I'm currently of the opinion that gnome made an initial decisions
>> and as reaction to that they are setting policy and that this will
>> be allowed under 6.1.1.
>
> It's clear that whether this kind of dependency is allowed is a key
> issue (perhaps even _the_ key issue) in this dispute. The question of
> the default init system is in some ways a proxy for the coupling
> question. And the extent and timing of such dependencies is clearly a
> matter that ought to be dealt with in the policy manual. So it is
> definitely a matter of technical policy.
>
> Whether the matter is ripe for the TC is not something that I would
> expect the Secretary to rule on. I think that's a matter for the TC.
So you suggest to just ignore "In each case the usual maintainer of the
relevant software or documentation makes decisions initially"?
If you decide on the init system question first, you could just file a
bug against debian-policy and things could go their usual way.
Alternatively, the Policy maintainers could defer this decision to the
technical committee under 6.1.3.
> But even if it is for the Secretary to rule on, I hope that the
> Secretary will agree that it's clear that the question is ripe for a
> TC decision (if not wildly overdue).
Can the Secretary decide that the second part of 6.1.1 is to be ignored?
Ansgar
--
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/52f50dd7.3000...@debian.org
Re: Bug#727708: Both T and L are wrong, plea for something simpler
On 02/06/2014 11:50, Colin Watson wrote: > I don't interpret L as meaning that everything must support "all" init > systems, certainly not "alike" (indeed the text of that option is > explicit that it isn't necessarily alike). Rather, I interpret it as > saying that software-outside-init must be flexible enough to cope with > that possibility, and degrade sensibly to a lowest common subset of init > system features (IOW in practice, needs to keep working if sysvinit is > pid 1). Actual support for things beyond that minimum will require > people who care about various init systems to step up and implement it. What does this mean in the concrete example that lead to the ctte bug? That is: Provided logind is only provided by systemd (the current situation). May GNOME depend on logind? If not, do you plan to override the GNOME maintainers with this decision? Ansgar -- 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/52f36c61.3090...@debian.org
Re: Additional CTTE Drafting Meeting useful?
Hi, On 02/06/2014 06:33, Russ Allbery wrote: > Don Armstrong writes: >> Would one more IRC meeting be useful to nail down the ballot options and >> their drafts? > > I personally suspect that we have exhausted the capacity of the TC to deal > with this problem, and that spending more time on it may actually result > in worse decisions than we would make right now. Currently, I like each > ballot we're getting less than I liked the previous one. So I'm dubious. Voting FD again due to failing to agree on a ballot might also indicate that the secondary question (allowing dependencies on functionality only available with a subset of existing init systems) have not been reasonably discussed elsewhere (as required by 6.3.5). In this case I suggest to decide just the question of the default init system on Linux architectures first and address further details later if no consensus can be found elsewhere. Finding the correct wording then should be easier. The init system vote could than have the options Bdale suggested earlier, with addition of a suitable GR override paragraph. The latter addition seemed at least uncontroversional except for a few wording issues. > Chances are quite high that this will be decided by GR anyway at this > point. In that case we could also just start the GR now. I don't think we win anything by delaying this decision further and further. In contrast, it will mean we will fix *less* integration bugs before the freeze if the init system changes. Ansgar -- 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/52f36793.6050...@debian.org
Bug#727708: multiple init systems - formal resolution proposal
Adrian Bunk writes: > On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote: >>... >> > == version "multiple" only == >> > >> >2. Debian intends to support multiple init systems, for the >> > foreseeable future, and so long as their respective communities >> > and code remain healthy. Nothing outside of an init system's >> > implementation may require a specific init system to be pid 1. >> >> It's unclear if reduced functionality (or in the extreme case no >> functionality) would satisfy this. >> >> Would a gnome-session-systemd package that requires systemd violate >> this (if gnome-session is also available)? >>... > > You are forgetting the best technical solution, which is what > gnome-session is actually implementing at the moment: > > session_tracking="systemd (with fallback to ConsoleKit)" [1] No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. Ansgar -- 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/87zjmg60ft@deep-thought.43-1.org
Bug#727708: multiple init systems - formal resolution proposal
Hi,
Ian Jackson writes:
> Ian Jackson writes ("Bug#727708: multiple init systems - formal resolution
> proposal"):
>> I hereby propose the following resolution:
>>
>>1. Support for sysvinit is mandatory in jessie.
>
> I hereby propose and accept an amendment to add a new rubric paragraph
> 0, and I also propose and do NOT accept an amendment to delete
> paragraph 2, so as to result in the following proposal:
>
> == both versions ==
>
>0. We exercise our power to set policy, Constitution 6.1.1:
6.1.1 states "In each case the usual maintainer of the relevant software
or documentation makes decisions initially, however; see 6.3(5).".
So in this case the Policy editors should make the decision
initially. The ctte can then override them, but would require a 3:1
majority (unless the Policy editors defer the issue under 6.1.3).
>1. Support for sysvinit is mandatory in jessie.
This is a "should" currently (Policy 9.3.2). Do you plan to change this
to a "must"?
Would git-daemon-run violate this? Note that git-daemon-run provides
sysvinit integration.
> == version "multiple" only ==
>
>2. Debian intends to support multiple init systems, for the
> foreseeable future, and so long as their respective communities
> and code remain healthy. Nothing outside of an init system's
> implementation may require a specific init system to be pid 1.
It's unclear if reduced functionality (or in the extreme case no
functionality) would satisfy this.
Would a gnome-session-systemd package that requires systemd violate
this (if gnome-session is also available)? If yes, what is the reason
for forbidding people from trying out new things?
Ansgar
--
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/87ha8pt3ny@deep-thought.43-1.org
Bug#727708: Init system resolution open questions
Hi, Adrian Bunk writes: > On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote: >>... >> Maintainers only should not drop support for a (default) init system >> when the application supports it. >>... > > So if udev (maintained by systemd upstream as part of the systemd > sources) would ever get a dependency on systemd being the init > system,[1] that should be fine even when the decision of Debian > was to support multiple init systems? If it doesn't work at all without systemd enabled, yes. Note that this doesn't stop people from keeping it working without systemd in which case it wouldn't need this dependency. Having already existing packages gain a dependency on a specific init system is probably more controverse and more people might want to avoid that[1], but that is (IMHO) no reason to forbid such dependencies altogether. Ansgar [1] That's why there was a footnote in my earlier mail. -- 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/878uufhwy6@deep-thought.43-1.org
Bug#727708: Init system resolution open questions
Hi, Ian Jackson writes: > AFAICT we are all agreed that: [...] > * Applications which aren't part of the init system must not require a > particular init to be pid 1. (So in particular a desktop > environment may not require a particular pid 1.) What about applications that are specifically designed to work with a particular init system? DSA was investigating setting up systemd for codesearch.debian.net which uses it to manage worker pools (including startup via socket activation and load balancing IIRC). Another example would be a seperate gnome-session-systemd package[1]. I don't think tech-ctte should forbid people to maintain such packages if they wish to. [1] Let's assume this only provides a (possibly non-default) alternative for and doesn't replace gnome-session here. Of course these might work (partially) if someone implemented enough of the systemd dbus interfaces to make the user systemd work without systemd being pid-1 as well. However (without having investigated this) I would assume this unlikely to happen. Maintainers only should not drop support for a (default) init system when the application supports it. This would be similar to the situation with different kernels: when applications support all of them, fine, but there may be programs that require a specific kernel. Ansgar -- 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/877g9zek52@deep-thought.43-1.org
