On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote:
Afaict we have still no idea on how to move on.
1 I think you agree that there is a significant number of usrmerged Debian
installations out there.
My wish would be to indeed salvage those systems,
that's why I implemented dpkg-fsys-usrunmess.
2 As you have stated there are known issues with dpkg and usrmerged
systems. Some of them are are triggered by moving files from / to /usr.
Well, in my mind the first and most immediate action that would be
done, is to stop the bleeding, by:
- reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
- reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
I do not believe it will be possible at this point to
convince the project as a whole to unwind usrmerge and go back to doing individual package migrations.
Given that as a design constraint (we will not be doing this transition
via one-by-one changes to each package), what would you support as a good architectural solution to this transition?
- reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
- reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
This bullet point response confuses me - and then what?
If I understand your position correctly, you don't want merged-/usr as
an end-goal and you disagree with usrmerge transition as a hack. In
order to achieve the result above without bypassing Debian processes,
the formal method would to pass a GR overriding the tech-ctte minority.
Is the only reason you haven't proposed that as a GR that you've already
sunk too much energy into this? Or that you don't trust that process?
On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:
- reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
- reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
This bullet point response confuses me - and then what?
If I understand your position correctly, you don't want merged-/usr as
an end-goal and you disagree with usrmerge transition as a hack. In
order to achieve the result above without bypassing Debian processes,
the formal method would to pass a GR overriding the tech-ctte minority.
Is the only reason you haven't proposed that as a GR that you've already sunk too much energy into this? Or that you don't trust that process?
My question is the reverse. If there is rough consensus that we as a community *do* want to go forward with /usr unification in a way which
is compatible with all of the other distrubtions --- and Debian is
definitely in thet trailing edge here --- and a very small number of
dpkg developers are refusing to help resolve these issues, are they
entitled to perform a pocket veto on /usr unification?
Simon and I have proposed technical paths forward which appear to be
sound, and I note that Guillem has not commented on them. Which is
why I haven't really participated in this thread in the last couple of
days; I've said my piece, and if folks who essentially want to
rollback the clock by several years refuse to engage, just simply
repeating my points doesn't seem to be a good use of electrons.
But the question remains --- how do we as a community move forward?
Debian is made up of volunteers, so we can't *force* the dpkg
developers to do anything they don't want to do. So what then?
Does someone need to create patches to dpkg which attempt to teach it
that /bin/foo and /usr/bin/foo are the same file, if there exists a
symlink from /bin to usr/bin? And then with some kind of process,
maybe with the blessing of the technical committee, upload it as an
NMU over the objections of the dpkg developers if they continue to
refuse to engage with solutions that proceed forward with
/usr-unification? That seems to be rather non-ideal from a community perspective. But what's the alternative? Should a single DD have the
power to overturn a techical committee because they are the maintainer
of a highly important package? That doesn't seem great, either.
As I've said before, I've never been a fan of /usr-unification; I
don't hate it, but I've never thought it was worth it in and of
itself, other the "compatibility with the rest of the world argument".
I'm not a huge fan of systemd, either, although I never hated it as
much as some. But the entire Linux ecosystem has spoken, and so my
personal views aren't really important at this point. Part of living
in a community is realizing that one doesn't always get one's own way,
and subsuming one's individual wants for the greater good.
So I repeat the question to the entire community --- what is to be
done? How do we move forward?
- Ted
Le ven. 27 août 2021 à 17:20, Theodore Ts'o <tytso@mit.edu> a écrit :
On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:
- reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
- reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
This bullet point response confuses me - and then what?
If I understand your position correctly, you don't want merged-/usr as
an end-goal and you disagree with usrmerge transition as a hack. In
order to achieve the result above without bypassing Debian processes,
the formal method would to pass a GR overriding the tech-ctte minority.
But the question remains --- how do we as a community move forward?
Debian is made up of volunteers, so we can't *force* the dpkg
developers to do anything they don't want to do. So what then?
Does someone need to create patches to dpkg which attempt to teach it
that /bin/foo and /usr/bin/foo are the same file, if there exists a
symlink from /bin to usr/bin?
So I repeat the question to the entire community --- what is to be
done? How do we move forward?
See the proposal here of guillem: https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
[ ] (blocker) dpkg database access (.list and .md5sums)
* reportbug (no interface to map a db pathname to a pkgname)
[ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ because old or new .debs could have shipped those, and these might be invalid, or not match the contents. In general it seems like a bad
idea to store the files handled and generated by dpkg itself, with
files coming straight from the .debs. We need to separate them into
different directories. Perhaps /var/lib/dpkg/info/<pkg>.<ctrl-file>
and /var/lib/dpkg/meta/<pkg>.<meta-file> or similar.
Does someone need to create patches to dpkg which attempt to teach it
that /bin/foo and /usr/bin/foo are the same file, if there exists a
symlink from /bin to usr/bin?
And then with some kind of process,
maybe with the blessing of the technical committee, upload it as an
NMU over the objections of the dpkg developers if they continue to
refuse to engage with solutions that proceed forward with
/usr-unification?
Should a single DD have the
power to overturn a techical committee because they are the maintainer
of a highly important package?
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote:
Le ven. 27 août 2021 à 17:20, Theodore Ts'o <tytso@mit.edu> a écrit :ideally
On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:
- reverting the changes in deboostrap in sid, bullseye (and
includesin buster too),
- reverting the notion that split-/usr is unsupported (which
release-notes,the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as
This bullet point response confuses me - and then what?
asIf I understand your position correctly, you don't want merged-/usr
minority.an end-goal and you disagree with usrmerge transition as a hack. In order to achieve the result above without bypassing Debian processes, the formal method would to pass a GR overriding the tech-ctte
But the question remains --- how do we as a community move forward? Debian is made up of volunteers, so we can't *force* the dpkg
developers to do anything they don't want to do. So what then?
Does someone need to create patches to dpkg which attempt to teach it that /bin/foo and /usr/bin/foo are the same file, if there exists a symlink from /bin to usr/bin?
So I repeat the question to the entire community --- what is to be
done? How do we move forward?
See the proposal here of guillem: https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
Hi Bastien, it's hard for me to see as an outsider to dpkg how that
proposal specifically addresses merged-/usr. It seems to be trying to
solve a much, much more generalised problem of which merged-/usr is just
a part. Is there no way to achieve the goal of making the dpkg database correspond with reality without that complexity?
Secondly, assuming that this mechanism is needed, then according to that
wiki page it appears to be almost complete? Can you confirm that the
only thing needed to support merged-/usr as an option is these two
remaining blockers?
[ ] (blocker) dpkg database access (.list and .md5sums)
* reportbug (no interface to map a db pathname to a pkgname)
[ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ because old or new .debs could have shipped those, and these might be invalid, or not match the contents. In general it seems like a bad
idea to store the files handled and generated by dpkg itself, with
files coming straight from the .debs. We need to separate them into different directories. Perhaps /var/lib/dpkg/info/<pkg>.<ctrl-file>
and /var/lib/dpkg/meta/<pkg>.<meta-file> or similar.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 239:25:06 |
Calls: | 6,624 |
Files: | 12,172 |
Messages: | 5,320,000 |