Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1182132 > unrolled thread

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Helmut Grohne <helmut@subdivi.de> - 2024-01-13 08:30 +0100
    Bug#1058937: Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Helmut Grohne <helmut@subdivi.de> - 2024-01-17 15:20 +0100
      Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Matthew Vernon <matthewv@chiark.greenend.org.uk> - 2024-02-19 11:00 +0100
        Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Helmut Grohne <helmut@subdivi.de> - 2024-02-19 12:20 +0100
    Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Sam Hartman <hartmans@debian.org> - 2024-01-17 17:40 +0100
      Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Helmut Grohne <helmut@subdivi.de> - 2024-01-17 18:40 +0100
    Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Matthew Vernon <matthewv@chiark.greenend.org.uk> - 2024-02-19 11:00 +0100
      Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Helmut Grohne <helmut@subdivi.de> - 2024-02-19 12:20 +0100
      Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Sam Hartman <hartmans@debian.org> - 2024-02-20 16:30 +0100
        Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts Russ Allbery <rra@debian.org> - 2024-02-20 17:20 +0100

#1182132 — Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

Package: tech-ctte

Given our discussion at the last CTTE meeting, I am turning my request
for advice into a formal one.

Most of the /usr-move that is happening via DEP17 seems to be working
out, but the effects of Conflicts raise the question of what kinds of
interactions with a package manager are considered supported.

A naive reading of Debian policy 7.4 suggests that declaring a conflict
reliably prevents concurrent unpack:

| When one binary package declares a conflict with another using a
| Conflicts field, dpkg will refuse to allow them to be unpacked on
| the system at the same time.

If you account for the effects of aliasing, this turns out to be a too
naive reading as dpkg actually allows unpacking a conflicting package if
the other package is scheduled for removal. Normally, this exception
should not have observable consequences, but aliasing makes it
observable in the form of file loss. I have filed #1057199 to clarify
debian-policy.

I subsequently triggered the discussion of what kinds of upgrades we
consider supported on debian-devel@lists.debian.org and invited the CTTE
for feedback (20231221094157.GA2753481@subdivi.de). While there is a
preliminary conclusion, subsequent discussion in the last CTTE meeting
and elsewhere has shown some disagreement.

The relevant situation is not entirely trivial to construct:

 * Package $first contains an aliased file $file and this is moved to
   package $second in an update.
   OR
   Package $first diverts aliased location $file normally owned by
   package $second.

 * An update to package $second moves $file to its physical location
   below /usr.

 * Package $second declares a versioned conflict for package $first with
   any version that contains or diverts the aliased $file.

Then we can construct a file loss scenario:

 * Install package $first.
 * Schedule $first for removal:
   echo "$first remove" | dpkg --set-selections
 * Install the updated $second:
   dpkg --unpack $second.deb

In that last step, dpkg will unpack $second despite the conflicted
package $first still being unpacked. After performing the unpack, it
will remove package $first to honour the declared conflict. When doing
so, it will remove the aliased $file and in doing so remove the updated
$file at the physical location below /usr owned by package $second.

The following packages technically contain a conflict involving
aliasing:
 * bfh-container
 * busybox
 * busybox-static
 * busybox-syslogd
 * daemontools-run
 * dhcpcd-base
 * elogind
 * exfat-utils
 * exfatprogs
 * finit-sysv
 * inetutils-syslogd
 * libelogind0
 * libnfsidmap1
 * libsystemd0
 * molly-guard
 * openresolv
 * opensysusers
 * progress-linux-container
 * resolvconf
 * runit
 * runit-init
 * systemctl
 * systemd
 * systemd-resolved
 * systemd-standalone-sysusers
 * systemd-standalone-tmpfiles
 * systemd-sysv
 * sysvinit-core
 * udev
 * zabbix-proxy-mysql
 * zabbix-proxy-pgsql
 * zabbix-proxy-sqlite3
 * zabbix-server-mysql
 * zabbix-server-pgsql
The following files are affected (normalized to aliased representation):
 * /bin/busybox
 * /bin/loginctl
 * /bin/systemctl
 * /bin/systemd-sysusers
 * /bin/systemd-tmpfiles
 * /lib/dhcpcd/dhcpcd-hooks/01-test
 * /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf
 * /lib/dhcpcd/dhcpcd-hooks/30-hostname
 * /lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf
 * /lib/dhcpcd/dhcpcd-hooks/62-chrony.conf
 * /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
 * /lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf
 * /lib/dhcpcd/dhcpcd-run-hooks
 * /lib/systemd/system/sysinit.target.wants/systemd-hwdb-update.service
 * /lib/systemd/system/systemd-hwdb-update.service
 * /lib/systemd/system/zabbix-proxy.service
 * /lib/systemd/system/zabbix-server.service
 * /lib/udev/rules.d/70-uaccess.rules
 * /lib/udev/rules.d/71-seat.rules
 * /lib/udev/rules.d/73-seat-late.rules
 * /lib/x86_64-linux-gnu/libnfsidmap/nsswitch.so
 * /lib/x86_64-linux-gnu/libnfsidmap/regex.so
 * /lib/x86_64-linux-gnu/libnfsidmap/static.so
 * /lib/x86_64-linux-gnu/libnfsidmap/umich_ldap.so
 * /lib/x86_64-linux-gnu/libsystemd.so.0
 * /sbin/coldreboot
 * /sbin/exfatlabel
 * /sbin/fsck.exfat
 * /sbin/halt
 * /sbin/init
 * /sbin/mkfs.exfat
 * /sbin/pm-hibernate
 * /sbin/pm-suspend
 * /sbin/pm-suspend-hybrid
 * /sbin/poweroff
 * /sbin/reboot
 * /sbin/resolvconf
 * /sbin/runlevel
 * /sbin/shutdown
 * /sbin/syslogd
 * /sbin/telinit
 * /sbin/update-service

While systemctl, libsystemd.so.0 or systemd-sysusers may sound
important, these only are relevant when your upgrade migrates from
docker-systemctl-replacement, elogind or opensysusers during your
dist-upgrade.

The list is incomplete as there are patches adding more. For instance,
cryptsetup, gzip isc-dhcp-client and netplan-generator will likely gain
affected Conflicts. I expect that time64 might double the number.

I note that for the loss to happen, removal needs to be scheduled and
this is not something apt seems to do a lot. apt can be forced to
perform temporary removal using dpkg --set-selections by adding mutual
conflicts (mutual conflicts and breaks). At the time of this writing we
do not have any such mutual conflicts in the archive.

In most upgrade scenarios, apt will remove/upgrade package $first before
performing the unpack of $second. In these cases, no loss happens.

Therefore, I hope that the loss cannot be experienced when upgrading
with apt or frontends using apt such as aptitude, but there is no proof
of this.

For some of the conflicts we already added mitigations:
 * systemd-sysv.postinst restores what has been lost
 * gzip.postinst (#1059533) will restore what has been lost

Technically speaking, the change to gzip will introduce a policy
violation as essential packages are expected to work even when unpacked
and gzip will loose its e.g. /usr/bin/zcmp when zutils is upgraded or
removed and only regain it in gzip.postinst. (Again, no loss happens if
apt handles zutils before gzip or when no zutils is installed and that's
what I expect to happen.)

One takeaway from the CTTE meeting was that this loss should be
mitigated when it may make a system unbootable. That is a property that
is difficult to capture and would likely require mitigating half of the
conflicts.

The way of mitigation also is non-trivial. In the window between unpack
of files that will be lost and actual loss, no maintainer script is run
reliably. Hence, copies of affected files have to be installed
elsewhere:
 * systemd-sysv looses only symlinks whose target is specified in
   postinst.
 * gzip looses shell scripts that will be embedded in its postinst.
 * For larger files such as dhclient, we consider moving the file to an
   unaffected location and then pointing a symlink at it such that only
   the symlink needs to be restored.

As you can see, the proposed mitigation is not automatic and introduces
non-trivial code that can contain bugs of its own. The cost of applying
it is non-trivial while the chances of reproducing this kind of problem
in a real-world scenario seem small to me.

After an upgrade, loss can be diagnosed using `dpkg --verify` and any
loss can be rectified by reinstalling affected packages.

As you can see, the question at hand is not very boolean. For each
affected conflict we may consider:
 * How likely is it to encounter the loss (with apt / with dpkg)?
 * Has it been observed in a real upgrade? (We have no non-artificial
   reports yet.)
 * How much effort is it to develop the mitigation? (typically a few
   hours as testing is non-trivial still)
 * How likely is it to introduce new problems when doing so?
 * How many affected users will read release-notes before rebooting and
   mitigate the problem locally?
 * When will this mitigation be cleaned up?

For the gzip case, we have the additional question whether we tolerate
the temporary policy violation for the trixie upgrade or halt the
/usr-move and retry with a modified dpkg (that could land in trixie, so
we could complete in forky).

Quite obviously, I'm very biased here, because writing those patches
likely falls on me and I'd rather avoid that.

I also note that there may be unknowns beneath. In May last year, things
looked good, then we found empty directory loss and m-a:same shared file
loss. Then things looked good again until October when we found this.
Chances are, there are more unknowns.

If we want to conclude the transition in trixie, we have little options
but to move forward now. Doing so will cause more instances of this
problem category. Adding the mitigations later does not cause
significant extra costs compared to adding them immediately. As I do not
expect the CTTE reverting the /usr-merge for this issue, I'll be moving
forward with introducing more affected conflicts.

Helmut

[toc] | [next] | [standalone]

#1182631 — Bug#1058937: Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

On Fri, Jan 12, 2024 at 01:31:18PM +0100, Helmut Grohne wrote:
> The relevant situation is not entirely trivial to construct:
> 
>  * Package $first contains an aliased file $file and this is moved to
>    package $second in an update.
>    OR
>    Package $first diverts aliased location $file normally owned by
>    package $second.
> 
>  * An update to package $second moves $file to its physical location
>    below /usr.
> 
>  * Package $second declares a versioned conflict for package $first with
>    any version that contains or diverts the aliased $file.
> 
> Then we can construct a file loss scenario:
> 
>  * Install package $first.
>  * Schedule $first for removal:
>    echo "$first remove" | dpkg --set-selections
>  * Install the updated $second:
>    dpkg --unpack $second.deb

I somehow missed how Ben's libnfsidmap bug #1058937 works slightly
simpler. Given that $second has a conflict with the installed version of
$first, one can skip that second step and instead install $second
directly with dpkg -i. So no, this weird selections stuff is not
technically necessary.

In general, when doing these dances there are two outcomes. Either,
$first is unpacked (or removed) before $second is unpacked or the other
way round. The latter case always shows a message like this:

    dpkg: considering removing $first in favour of $second ...
    dpkg: yes, will remove $first in favour of $second

It is these cases that exhibit the buggy behaviour.

> In most upgrade scenarios, apt will remove/upgrade package $first before
> performing the unpack of $second. In these cases, no loss happens.

I tried to get an idea of what "most" means precisely. For one thing, I
constructed various bullseye->bookworm and bookworm->unstable upgrades
followed by dpkg --verify. This included large installations such as
task-gnome-desktop with recommends and targeted cases where I hoped to
find problems such as upgrading molly-guard or nfs-ganesha or and a few
more. In none of the cases (where doing plain apt-get dist-upgrade), I
was able to make dpkg --verify unhappy.

Another route was searching for existing evidence. piuparts has lots of
logs of upgrading packages and in >= bookworm, I found exactly one
having that "yes, will remove" content. It was
https://piuparts.debian.org/testing2sid/pass/rubber_1.6.0-2.log and
that's due to texlive-base declaring a versioned Conflict with
texlive-latex-base and texlive-latex-base declaring versioned Breaks
with texlive-base. This is the mutual Conflicts case that also broke
stuff in a draft patch for molly-guard. This data point confirms what
David Kalnischkies said about this earlier: In the absence of mutual
conflicts, apt removes $first before unpacking $second.

I also tried a web search for "yes, will remove" and really most of logs
I found, dpkg was used directly (though without --set-selections). That
texlive mutual conflict was an exception. Evidently, this is rarely
happening on real installations.

> Therefore, I hope that the loss cannot be experienced when upgrading
> with apt or frontends using apt such as aptitude, but there is no proof
> of this.

So all the evidence I found confirms the guess that the problem cannot
be observed with apt unless mutual conflicts exist. On the flip side,
simply installing a package that declares Conflicts occasionally
triggers this and if you happen to do this to a package that replaces
aliased files, then your files vanish.

In particular, this raises the question whether we consider the upgrade
that Ben describes in #1058937 as supported or whether we can close the
bug. In effect, that's the question to ask here.

I note that netplan.io/0.107.1-2/#1060661 just opted for not doing
Conflicts and instead employed protective diversions (M8). In principle,
we could generally prefer M8 (for P1, but not for P7) and thereby reduce
the problem at the cost of making the mitigation more complex. At least
for the essential set, there is not much choice as employing Conflicts
is known to lead to bad things.

> One takeaway from the CTTE meeting was that this loss should be
> mitigated when it may make a system unbootable. That is a property that
> is difficult to capture and would likely require mitigating half of the
> conflicts.

While this may seem like an obvious rule-of-thumb, it very much is
not. For many of the packages, one can plausibly construct crazy boot
schemes involving them. Though cryptsetup quite clearly falls within
scope.

> The way of mitigation also is non-trivial. In the window between unpack
> of files that will be lost and actual loss, no maintainer script is run
> reliably. Hence, copies of affected files have to be installed
> elsewhere:
>  * systemd-sysv looses only symlinks whose target is specified in
>    postinst.
>  * gzip looses shell scripts that will be embedded in its postinst.
>  * For larger files such as dhclient, we consider moving the file to an
>    unaffected location and then pointing a symlink at it such that only
>    the symlink needs to be restored.

This is the complex case where Conflicts are used to mitigate
ineffective diversions. Mitigating ineffective Replaces is a little
simpler. For instance,
https://salsa.debian.org/debian/netplan.io/-/commit/6e3a0b9a32f23291d32e0f61f1828be1aab52bf2
Doing the same thing for libnfsidmap is plausible at least.

And since we're likely going to mitigate cryptsetup and isc-dhcp-client
that doesn't leave many diversion cases and most of the remaining
conflicts could be augmented with these simpler protective diversions.
Striking a good balance here is hard.

Helmut

[toc] | [prev] | [next] | [standalone]

#1186701

On 17/01/2024 14:07, Helmut Grohne wrote:

> I somehow missed how Ben's libnfsidmap bug #1058937 works slightly
> simpler. Given that $second has a conflict with the installed version of
> $first, one can skip that second step and instead install $second
> directly with dpkg -i. So no, this weird selections stuff is not
> technically necessary.

To check I have understood correctly: one may see loss of files when 
doing dpkg -i of a package where it Conflicts: with an installed package?

If that's so, then I think it increases my unhappyness about this 
situation. I can understand "do upgrades with apt, that's the tooling 
for the job", and we had already talked about adding something to 
release notes to describe what manual actions that one might take during 
an upgrade were dangerous, but "dpkg -i foo.deb where foo.deb Conflicts 
with something you have installed" seems like the sort of thing one 
really might reasonably do during an upgrade that has got stuck for some 
reason or other.

Regards,

Matthew

[toc] | [prev] | [next] | [standalone]

#1186706

On Mon, Feb 19, 2024 at 09:48:00AM +0000, Matthew Vernon wrote:
> To check I have understood correctly: one may see loss of files when doing
> dpkg -i of a package where it Conflicts: with an installed package?

Unfortunately, this is real.

apt avoids this, because it recognizes that it can remove the conflicted
package before installing the other one.

> If that's so, then I think it increases my unhappyness about this situation.
> I can understand "do upgrades with apt, that's the tooling for the job", and
> we had already talked about adding something to release notes to describe
> what manual actions that one might take during an upgrade were dangerous,
> but "dpkg -i foo.deb where foo.deb Conflicts with something you have
> installed" seems like the sort of thing one really might reasonably do
> during an upgrade that has got stuck for some reason or other.

TBH, most of the time where I resort to dpkg -i foo.deb, foo was already
unpacked and I try again. In that scenario, apt will have resolved the
conflict already.

For the basic DEP17 P1 problem we now have more nuances of mitigations
that are spelled out in the DEP17 document.

The basic "upgrade Replaces to Conflicts" M7 mitigation is what we see
failing when using dpkg -i above. It can be augmented with temporary
(preinst -> postinst) protective diversions M8 to cover this case.

Note that just using those protective diversions M8 in isolation
actually is unsafe in theory as well. As we remove the diversions in
postinst, we may still loose files after that point when unpacking a
package that we moved a file from and then removing it again. Such a
package cannot be configured (due to Breaks), but it can still cause a
file to be lost. In a non-aliasing context, the declared Replaces would
ensure that the file is not stolen.

We can also extend those protective diversions M8 beyond postinst. This
is what we'll be doing for e.g. pam #1062802 and tirpc #1062801. This
will leave a completed trixie installation with lots of crazy
diversions, but there is no known way to break these with operating
dpkg in interesting ways.

I note that time64 has added quite some of these diversions (in
experimental).

It then becomes the question of how many packages should have their
protective diversions persisted rather than temporary. When we persist
them, we can remove them in forky and drop the removal code in forky+1,
which is a long time to carry cruft.

Helmut

[toc] | [prev] | [next] | [standalone]

#1182646

>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:

    Helmut> Package: tech-ctte Given our discussion at the last CTTE
    Helmut> meeting, I am turning my request for advice into a formal
    Helmut> one.

    Helmut> Most of the /usr-move that is happening via DEP17 seems to
    Helmut> be working out, but the effects of Conflicts raise the
    Helmut> question of what kinds of interactions with a package
    Helmut> manager are considered supported.

    Helmut> A naive reading of Debian policy 7.4 suggests that declaring
    Helmut> a conflict reliably prevents concurrent unpack:

    Helmut> | When one binary package declares a conflict with another
    Helmut> using a | Conflicts field, dpkg will refuse to allow them to
    Helmut> be unpacked on | the system at the same time.

    Helmut> If you account for the effects of aliasing, this turns out
    Helmut> to be a too naive reading as dpkg actually allows unpacking
    Helmut> a conflicting package if the other package is scheduled for
    Helmut> removal. Normally, this exception should not have observable
    Helmut> consequences, but aliasing makes it observable in the form
    Helmut> of file loss. I have filed #1057199 to clarify
    Helmut> debian-policy.

I'd really like to understand why this is desired dpkg behavior.
I appreciate that even if it is not desired behavior, we might not be
able to get it fixed in ways that matter for this discussion.
However my intuition is that it  will help me at least think about the
situation.
As an example if the reason that behavior is needed has to do with some
situation involving essential packages and conflicts, I'd like to
understand that situation and how common it is.
It would not be the first time in this discussion that we have
discovered a new complexity.

--Sam

[toc] | [prev] | [next] | [standalone]

#1182651

Hi Sam,

On Wed, Jan 17, 2024 at 09:33:25AM -0700, Sam Hartman wrote:
> I'd really like to understand why this is desired dpkg behavior.

I fear I have to defer to Guillem on this one. My rough understanding is
that we can minimize the window of time during which the files are
missing. Though given that apt only exercises this feature on mutual
conflicts and otherwise removes the conflicted package early, the
practical consequences of that reasoning may be questionable.

> I appreciate that even if it is not desired behavior, we might not be
> able to get it fixed in ways that matter for this discussion.

This is the main reason for me having skipped the question of whether
that behaviour is desirable.

> However my intuition is that it  will help me at least think about the
> situation.

That is a very sensible approach.

> As an example if the reason that behavior is needed has to do with some
> situation involving essential packages and conflicts, I'd like to
> understand that situation and how common it is.

Practically speaking, it cannot be very common. In the essential set, we
very much avoid Conflicts where possible and the DEP17 work will not
introduce Conflicts in the Priority: required set for mitigating P1
(file loss due to move between packages and from aliased to physical)
problems. All of those problems will use protective diversions that do
not run into the risk at hand. The one Conflicts that I plan to
introduce in essential is gzip -> zutils. Outside, apt prefers resolving
these by removing packages before there is a concurrent unpack
situation.

> It would not be the first time in this discussion that we have
> discovered a new complexity.

Sure thing. Late discovery of new complexities is the biggest risk of
the DEP17 transition.

Helmut

[toc] | [prev] | [next] | [standalone]

#1186702

Hi,

On 12/01/2024 12:31, Helmut Grohne wrote:

> For the gzip case, we have the additional question whether we tolerate
> the temporary policy violation for the trixie upgrade or halt the
> /usr-move and retry with a modified dpkg (that could land in trixie, so
> we could complete in forky).

What's the scope of dpkg modification needed here? And is likely the 
sort of thing the dpkg maintainers would accept. Were we not already in 
a bit of a mire here, it's not clear to me that policy is wrong here 
(and thus that we should set it aside).

> I also note that there may be unknowns beneath. In May last year, things
> looked good, then we found empty directory loss and m-a:same shared file
> loss. Then things looked good again until October when we found this.
> Chances are, there are more unknowns.

This continues to make me worry we are not on the path of robust 
engineering. But I appreciate I'm in a very small minority in that regard.

Regards,

Matthew

[toc] | [prev] | [next] | [standalone]

#1186707

On Mon, Feb 19, 2024 at 09:53:20AM +0000, Matthew Vernon wrote:
> On 12/01/2024 12:31, Helmut Grohne wrote:
> 
> > For the gzip case, we have the additional question whether we tolerate
> > the temporary policy violation for the trixie upgrade or halt the
> > /usr-move and retry with a modified dpkg (that could land in trixie, so
> > we could complete in forky).

I note that this question fortunately no longer is relevant. The problem
there was that when zutils is removed as part of the upgrade, there was
no fixed zutils that could help with resolving the situation. Turning
this insight upside down means that gzip's maintainer scripts have to
help here. That's what I ended up proposing in
https://bugs.debian.org/1059534#30 and as likewise for
cryptsetup/cryptsetup-nuke-password and isc-dhcp. While none of these
has reached unstable yet, no problems are known with this approach
beyond being a layer violation: The diverted package now has to support
the diverting package in managing its diversions (until trixie is
released).

> What's the scope of dpkg modification needed here? And is likely the sort of
> thing the dpkg maintainers would accept. Were we not already in a bit of a
> mire here, it's not clear to me that policy is wrong here (and thus that we
> should set it aside).

I discussed a possible temporary feature of dpkg with Guillem. We could
temporarily (trixie+forky) change the semantics of dpkg (and then revert
the change). Whenever dpkg is about to delete a file, it would determine
the realpath of the file to be deleted according to the filesystem. This
is a noticeable slowdown as deletion is a frequent operation in package
upgrades. It would also require reimplementing dpkg-realpath in C (there
is a poc). When the realpath of the file to be deleted differs from the
looked up filename and is found to be owned by a package in the dpkg
database, dpkg would skip the deletion and issue a warning. The warning
would serve as a reminder that this changed behaviour should not be
relied upon for future upgrades. The reason we discarded this option was
timing: Using this approach would have meant that we could only start
moving files after the release of trixie.

Bumping back this transition seems harder and harder now. I think we are
half-way through the conversion (in terms of package count) with a focus
on non-trivial situations. Moving back would cause significant breakage
at this time.

> This continues to make me worry we are not on the path of robust
> engineering. But I appreciate I'm in a very small minority in that regard.

This was known right from the start of DEP17 when Luca Boccassi proposed
"let's just move all the files". We immediately identified that this
path was not robust spelling out a significant fraction of problems
right from the start. I tried to reconcile consensus repeatedly and
there were little objections when I concluded that we'd move forward
with this despite its known fragility.

Helmut

[toc] | [prev] | [next] | [standalone]

#1186813

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Matthew" == Matthew Vernon <matthewv@chiark.greenend.org.uk> writes:
    Matthew> This continues to make me worry we are not on the path of
    Matthew> robust engineering. But I appreciate I'm in a very small
    Matthew> minority in that regard.

I want to second the above.
I do still believe that the way forward is through rather than by
backing out and starting over.
However, I think it is essential that we spend significant time figuring
out how we can do better with future upgrades and decision processes,
possibly at a point where we have enough distance that we can hear each
other without anger, while not so much distance that we have lost the
technical detail.

As an example, if I had known protective diversions would be part of the
solution back when debating whether merged /usr was something we were
ready to do, I would have said we absolutely were not ready to go down
the path until we had better architected tools.

I'm not proposing to turn around now, and that may possibly be an area
where Matthew and I disagree.  But I absolutely want to lend credibility
to the idea that we are digging ourselves into a hole, hoping that it
will become a tunnel and we will find light at the other end.

--Sam

[toc] | [prev] | [next] | [standalone]

#1186818

Sam Hartman <hartmans@debian.org> writes:

> However, I think it is essential that we spend significant time figuring
> out how we can do better with future upgrades and decision processes,
> possibly at a point where we have enough distance that we can hear each
> other without anger, while not so much distance that we have lost the
> technical detail.

+1

There were some very important technical and social lessons to be learned
from this whole process, as well as a whole lot of incredibly valuable
research and a greater understanding of some misunderstandings and
fragility in how are full ecosystem of packaging tools fits together.  I
think the only way out for the /usr-merge transition specifically is
through, and until we finish that we're probably not in a good position to
absorb those lessons in a more comprehensive way, but I hope we don't skip
that step.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web