On Thu, Aug 26, 2021 at 02:56:21AM +0200, Guillem Jover wrote:

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,

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?

Lets say you get your wish: to achieve technical excellence the Project
backs your position and recommends running usrunmess to ensure
everyone's systems are back to split-/usr for Debian 12. However, hypothetically, and against your better judgement, the Project still
wants the end-goal to be merged-/usr.

It seems to me that most commentators are deferring to your knowledge of
dpkg internals. Whether you call it a feature request or a long-standing
bug, what patchset would you be willing to merge into dpkg to support
the new layout? This is a similar scenario to Russ' parallel email:

On Wed, Aug 25, 2021 at 01:23:19PM -0700, Russ Allbery wrote:

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?

What is the technically excellent thing everyone else should be working
on, that you will support in dpkg despite personally disagreeing with
the end-goal of merged-/usr? Presumably this feature could also be
implemented in time for Debian 12. Would it then be possible to make
everyone's systems merged-/usr upon release of Debian 13, in 2025?

I'm sorry, you won't know me from adam, so I hope you don't interpret
this as pro-merged-/usr, but as a chance to explain how you getting your
way doesn't stand in the way of what others consider timely progress.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYShQeQAKCRDbymUJHySO bJJWAQDwo8SJA7vUbVJSPgBPU0BPCJ+gV9MjEvYEGqm0vE3UIwEA+QTkJgTnDIk2 pKx0y2JaNhjkkFxK/1SPAeQ7uGGWkgc=
=dpI8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le ven. 27 août 2021 à 17:20, Theodore Ts'o <[email protected]> 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.
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?

See the proposal here of guillem: https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking

- Ted

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 27 août 2021 à 17:20, Theodore Ts&#39;o &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; a écrit :<br></div><blockquote class="gmail_quote" style="
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:<br>
&gt; &gt;   - reverting the changes in deboostrap in sid, bullseye (and ideally<br>
&gt; &gt;     in buster too),<br>
&gt; &gt;   - reverting the notion that split-/usr is unsupported (which includes<br>
&gt; &gt;     the extremely confusing interpretation about this applying to<br>
&gt; &gt;     sid/testing too), and update documentation such as release-notes,<br>
&gt; <br>
&gt; This bullet point response confuses me - and then what?<br>
&gt; <br>
&gt; If I understand your position correctly, you don&#39;t want merged-/usr as<br>
&gt; an end-goal and you disagree with usrmerge transition as a hack. In<br> &gt; order to achieve the result above without bypassing Debian processes,<br> &gt; the formal method would to pass a GR overriding the tech-ctte minority.<br>
&gt; Is the only reason you haven&#39;t proposed that as a GR that you&#39;ve already<br>
&gt; sunk too much energy into this? Or that you don&#39;t trust that process?<br>

My question is the reverse.  If there is rough consensus that we as a<br> community *do* want to go forward with /usr unification in a way which<br>
is compatible with all of the other distrubtions --- and Debian is<br> definitely in thet trailing edge here --- and a very small number of<br>
dpkg developers are refusing to help resolve these issues, are they<br> entitled to perform a pocket veto on /usr unification?<br>

Simon and I have proposed technical paths forward which appear to be<br>
sound, and I note that Guillem has not commented on them.  Which is<br>
why I haven&#39;t really participated in this thread in the last couple of<br> days; I&#39;ve said my piece, and if folks who essentially want to<br>
rollback the clock by several years refuse to engage, just simply<br>
repeating my points doesn&#39;t seem to be a good use of electrons.<br>

But the question remains --- how do we as a community move forward?<br>
Debian is made up of volunteers, so we can&#39;t *force* the dpkg<br> developers to do anything they don&#39;t want to do.   So what then?<br>

Does someone need to create patches to dpkg which attempt to teach it<br>
that /bin/foo and /usr/bin/foo are the same file, if there exists a<br>
symlink from /bin to usr/bin?  And then with some kind of process,<br>
maybe with the blessing of the technical committee, upload it as an<br>
NMU over the objections of the dpkg developers if they continue to<br>
refuse to engage with solutions that proceed forward with<br> /usr-unification?  That seems to be rather non-ideal from a community<br> perspective.  But what&#39;s the alternative?  Should a single DD have the<br>
power to overturn a techical committee because they are the maintainer<br>
of a highly important package?  That doesn&#39;t seem great, either.<br>


As I&#39;ve said before, I&#39;ve never been a fan of /usr-unification; I<br> don&#39;t hate it, but I&#39;ve never thought it was worth it in and of<br> itself, other the &quot;compatibility with the rest of the world argument&quot;.<br>
I&#39;m not a huge fan of systemd, either, although I never hated it as<br> much as some.  But the entire Linux ecosystem has spoken, and so my<br> personal views aren&#39;t really important at this point.  Part of living<br> in a community is realizing that one doesn&#39;t always get one&#39;s own way,<br>
and subsuming one&#39;s individual wants for the greater good.<br>

So I repeat the question to the entire community --- what is to be<br>
done?  How do we move forward?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">See the proposal here of guillem:</div><div dir="auto"><a href="https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking">https://wiki.debian.org/Teams/
Dpkg/Spec/MetadataTracking</a><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

                                        - Ted<br>

</blockquote></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote:

Le ven. 27 ao�t 2021 � 17:20, Theodore Ts'o <[email protected]> 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

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.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYSkv7wAKCRDbymUJHySO bHfqAP0U5LU91elUbXuZSco7+s/+7x7t587/0YE3Flc4u0woDQD/exoZt1xff1la 5FH+TUg+ZOLi4FlZjjsMEFy0rZGtMgE=
=s5va
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EoaM4VhWnazxzW3vxPb1ztUR9TfoThzRi
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 8/27/21 10:20 AM, Theodore Ts'o wrote:

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?

Yes. I can't speak to the dpkg internals, but conceptually, this seems
like the right thing to do.

Even if we eliminated usrmerge entirely, I'm not sure what's harmful
about dpkg canonicalizing filenames. In fact, it seems very much like
the right thing to do. So unless the patch is very invasive, I don't see
why one would object to this change on its own.

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?

Yes.

If the dpkg maintainer does not accept a reasonable patch, then this may
need to be presented to the TC to overrule him, which requires a 3:1 TC majority. One might argue the existing TC decision implies this, but the
least ambiguous procedural option would be to have the TC explicitly
overrule the maintainer once a specific implementation is available.

It is my view that the usrunmess utility also needs to be dropped before
the bookworm release. That quite clearly follows from the existing TC decision, which is that only the merged-usr layout is supported, so I
don't think that needs further TC action. However, I think removing that utility should wait until such time as we have the other issues
reasonably resolved.

Should a single DD have the
power to overturn a techical committee because they are the maintainer
of a highly important package?

No. This is settled in the Debian constitution. If a DD wishes to
override the TC, they need to propose a GR.

--
Richard


--EoaM4VhWnazxzW3vxPb1ztUR9TfoThzRi--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAmEpNpMACgkQ+HlhmcBF hs4Rwg/+PIMCgmPIJOxyyoSdBxdL++DPev1+9zedcGxcu11yKt576Ajxia4fLhjM sPZk2vAdVBNNFZtpuOL7N7rx3mP8zP6TyezO8zWe2Rdg7FpDKoe3UE2/7OT+/Dw3 VuroB/EIh+Ng7Qsnr/0Ggjk2BA8PQoG7MJepSpb5F2h2Tvup4NbnVISaosbRBwpy zgFM692SfSPonEIOkngqSGCz8hiQjaXNS8Ro608i9+hGlMm946DWmsgcylrtUBbw b2sk0dAuWuaR4/IJyqoeCIMka2w05oHFS0HNAiwQ28VP9eVJCf0lxQHXJSU+Uwpr xbQFUHUNfAF+cKvHHX1tUfp6e2w7zsjpAh0gNwh8kR1khu9o29zdgCQ4l9bJGGSN eVJ34lRm0UP/qw3LcK+oyAa/dQR2LjSu3xAkRVCuamY5boZmiDye3mIFHI7s3Mss vNiX7QsumQVVuAdcPAx+mcIw69cadIDKpCFjqsCSJ2HtPAE/VSIOCIJY8zmZdnV4 TY1klZQak0678ANgNOz3bEaZ9ES3j7Zd3GK+RpqaOKhLkF2AsFIDzQQJHMpfoJpN ZjmXpevEaLrYWq2gFudaJ2zCu2+OkTGME0IOv04tglCVG1VxIlupygCNM9v8YLY5 AM/ff/AWKd+FrrpA0EOS1+IXNr7w8qPMXw9zGGby9g04E+gXNX8=
=eJB/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le ven. 27 août 2021 à 20:33, Phil Morrell <[email protected]> a écrit :

On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote:

Le ven. 27 août 2021 à 17:20, Theodore Ts'o <[email protected]> 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

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?

No it will be more complex to spécial case then to solve thé général dir to symlink problem. Dpkg is a graph mathematical solver and as usual un math solving général problem ils often easier

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.

Yes ans no.

It is a needed condition to track symlink dir between package.

After it will need the same mécanism than that i have implemented with dpkg-maintscript-helper. But instead of failling like now when some file
under dir are owned by otherpackage, we could do something sensible and
notify thé other packages that dir is now symlink

Bastien



<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 27 août 2021 à 20:33, Phil Morrell &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; a écrit :<br></div><blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote:<br>
&gt; Le ven. 27 août 2021 à 17:20, Theodore Ts&#39;o &lt;<a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a>&gt; a écrit :<br>
&gt; &gt; On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:<br> &gt; &gt; &gt; &gt;   - reverting the changes in deboostrap in sid, bullseye (and ideally<br>
&gt; &gt; &gt; &gt;     in buster too),<br>
&gt; &gt; &gt; &gt;   - reverting the notion that split-/usr is unsupported (which includes<br>
&gt; &gt; &gt; &gt;     the extremely confusing interpretation about this applying to<br>
&gt; &gt; &gt; &gt;     sid/testing too), and update documentation such as release-notes,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This bullet point response confuses me - and then what?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If I understand your position correctly, you don&#39;t want merged-/usr as<br>
&gt; &gt; &gt; an end-goal and you disagree with usrmerge transition as a hack. In<br>
&gt; &gt; &gt; order to achieve the result above without bypassing Debian processes,<br>
&gt; &gt; &gt; the formal method would to pass a GR overriding the tech-ctte minority.<br>
&gt; &gt;<br>
&gt; &gt; But the question remains --- how do we as a community move forward?<br>
&gt; &gt; Debian is made up of volunteers, so we can&#39;t *force* the dpkg<br> &gt; &gt; developers to do anything they don&#39;t want to do.   So what then?<br>
&gt; &gt;<br>
&gt; &gt; Does someone need to create patches to dpkg which attempt to teach it<br>
&gt; &gt; that /bin/foo and /usr/bin/foo are the same file, if there exists a<br>
&gt; &gt; symlink from /bin to usr/bin?<br>
&gt; &gt;<br>
&gt; &gt; So I repeat the question to the entire community --- what is to be<br>
&gt; &gt; done?  How do we move forward?<br>
&gt; <br>
&gt; See the proposal here of guillem:<br>
&gt; <a href="https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking" rel="noreferrer noreferrer" target="_blank">https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking</a><br>

Hi Bastien, it&#39;s hard for me to see as an outsider to dpkg how that<br> proposal specifically addresses merged-/usr. It seems to be trying to<br>
solve a much, much more generalised problem of which merged-/usr is just<br>
a part. Is there no way to achieve the goal of making the dpkg database<br> correspond with reality without that complexity?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No it will be more complex to spécial case then to solve thé général dir to symlink problem. Dpkg is a graph mathematical solver
and as usual un math solving général problem ils often easier </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Secondly, assuming that this mechanism is needed, then according to that<br> wiki page it appears to be almost complete? Can you confirm that the<br>
only thing needed to support merged-/usr as an option is these two<br> remaining blockers?<br>

&gt; [ ] (blocker) dpkg database access (.list and .md5sums) <br>
&gt;     * reportbug (no interface to map a db pathname to a pkgname) <br> &gt; [ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/<br> &gt; because old or new .debs could have shipped those, and these might be<br> &gt; invalid, or not match the contents. In general it seems like a bad<br> &gt; idea to store the files handled and generated by dpkg itself, with<br> &gt; files coming straight from the .debs. We need to separate them into<br> &gt; different directories. Perhaps /var/lib/dpkg/info/&lt;pkg&gt;.&lt;ctrl-file&gt;<br>
&gt; and /var/lib/dpkg/meta/&lt;pkg&gt;.&lt;meta-file&gt; or similar.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes ans no.</div><div dir="auto"><br></div><div dir="auto">It is a needed condition to track symlink dir between
package.</div><div dir="auto"><br></div><div dir="auto">After it will need the same mécanism than that i have implemented with dpkg-maintscript-helper. But instead of failling like now when some file under dir are owned by otherpackage, we could do
something sensible and notify thé other packages that dir is now symlink</div><div dir="auto"><br></div><div dir="auto">Bastien</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
</blockquote></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)