Re: next steps after usrunmess
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
Re: next steps after usrunmess
Le ven. 27 août 2021 à 17:20, Theodore Ts'o 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 > >
Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > Le ven. 27 août 2021 à 17:20, Theodore Ts'o 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/. > and /var/lib/dpkg/meta/. or similar. signature.asc Description: PGP signature
Re: next steps after usrunmess
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 OpenPGP_signature Description: OpenPGP digital signature
Re: next steps after usrunmess
Le ven. 27 août 2021 à 20:33, Phil Morrell 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 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/. > > and /var/lib/dpkg/meta/. 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 >
