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 :
> > 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