Re: /usr-merge: continuous archive analysis
Hi Andreas, On Sun, Aug 06, 2023 at 06:44:47PM +0200, Andreas Metzler wrote: > Somehow related: If I introduce a new systemd unit should I work > around dh_installsystemd and ship it in /usr/lib/systemd/system/? Doing this is extra work now. If done correctly, it is compatible with the file move moratorium. Some packages declare a trigger interest for the aliased location and will have their triggers missed as you move to /usr, but I've already filed bugs for all affected packages so this is temporary at best. In general, I am in favour of this. > At first glance it seemed like a good idea (not adding to the problem) > but doubt there is real benefit. - Another binary package in the same > source already ships a unit that will need to be moved so we will need > to use $magic anyway. FWIW I would have used something like this: I also agree with this with a little caveat. Quite a number of available mitigations incur a cost per file. So by moving that secondary unit now, you may be lucky and avoid a mitigation for it later. > override_dh_installsystemd: > dh_installsystemd > mv debian/foo/lib/systemd/system \ > debian/foo/usr/lib/systemd/ Consider execute_after_dh_installsystemd. Other than that, this is the way to go. If you were to move before dh_installsystemd you'd miss maintainer scripts activating/starting your unit. > (I am assuming dh_installsystemd would not start installing stuff into > /usr/lib without a dh_compat bump.) We don't have consensus on this yet, but I agree with you here. My preferred way of implementing the merge in debhelper is adding a new dh_usrmerge that would perform the merge. It would come with a sequence addon "usrmerge" which would be enabled in a new compat level. Once the moratorium is lifted, you can: * opt in: Explicitly call dh_usrmerge * opt in: Build-Depends: dh-sequence-usrmerge * opt out: Bump compat level and pass --without=usrmerge to dh The downside of this approach (and why people disagree with it) is that we need at least one upload with source changes for every affected package. Yes, this does mean 2000 uploads. This is not backed by code yet, but you may disagree with it already. Helmut
Re: /usr-merge: continuous archive analysis
On 2023-08-01 Helmut Grohne wrote: [...] > In moving crontab_setgid from lib to libexec, you effectively evade the > moratorium and are entitled to also move from / to /usr. This is an > action you can do right now. The move from /lib to /usr/libexec prevents > the file loss scenario that spurred the moratorium. [...] Hello, Somehow related: If I introduce a new systemd unit should I work around dh_installsystemd and ship it in /usr/lib/systemd/system/? At first glance it seemed like a good idea (not adding to the problem) but doubt there is real benefit. - Another binary package in the same source already ships a unit that will need to be moved so we will need to use $magic anyway. FWIW I would have used something like this: override_dh_installsystemd: dh_installsystemd mv debian/foo/lib/systemd/system \ debian/foo/usr/lib/systemd/ (I am assuming dh_installsystemd would not start installing stuff into /usr/lib without a dh_compat bump.) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: /usr-merge: continuous archive analysis
Hi Alexandre, On Mon, Jul 31, 2023 at 01:37:12PM +0200, Alexandre Detiste wrote: > [systemd-cron]: after a carefull review, I took a third option: > these scriptlets belong neither in /lib nor /usr/lib but in /usr/libexec . > > This is now implemented this way in the upstream repository. > > The debian postinst will be adapted to > remove the old override in a next upload. This is halfway good and halfway bad. In moving crontab_setgid from lib to libexec, you effectively evade the moratorium and are entitled to also move from / to /usr. This is an action you can do right now. The move from /lib to /usr/libexec prevents the file loss scenario that spurred the moratorium. In https://github.com/systemd-cron/systemd-cron/commit/45e82678f62f523417b0c7f84d40ec7fcb1b864d, you move the generators from / to /usr. This action is prohibited by the moratorium and will have to be temporarily reverted in the packaging (or the upload of the upstream release needs to be delayed). Helmut
Re: /usr-merge: continuous archive analysis
Le ven. 21 juil. 2023 à 16:48, Helmut Grohne a écrit : > TL;DR: dpkg-statoverride detection cannot be automated, but there are > only 5 affected packages. > > On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > > * DEP17-P5: dpkg-statoverrides not matching the files shipped. > >Possibly, I can extend dumat to cover unconditional statoverrides. > > Changes needed: > * fuse (queries only, can be duplicated now) > * fuse3 (queries only, can be duplicated now) > * ntfs-3g (queries only, can be duplicated now) > * systemd-cron (needs to be updated when moving files) > * yp-tools (needs to be updated when moving files) [systemd-cron]: after a carefull review, I took a third option: these scriptlets belong neither in /lib nor /usr/lib but in /usr/libexec . This is now implemented this way in the upstream repository. The debian postinst will be adapted to remove the old override in a next upload. Greetings, Alexandre
Re: /usr-merge: continuous archive analysis
Hi, TL;DR: dpkg-statoverride detection cannot be automated, but there are only 5 affected packages. On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > * DEP17-P5: dpkg-statoverrides not matching the files shipped. >Possibly, I can extend dumat to cover unconditional statoverrides. In retrospect, this feels like a lie. As usual, the story is more complex than it initially seems. A really big chunk of users just queries a path for a (local) override. We cannot capture these by looking how a chroot was modified during maintainer scripts. Another significant chunk is conditional statoverrides that depend on either debconf answers or failure to apply filesystem capabilities. Observing the intended outcome in these cases is next to impossible. Actually parsing shell scripts and extracting those calls is what I tried for diversions first, but that runs afoul variable interpolation and the halting problem before too long. So really, I don't see a good way to implement the promised detection without a high error rate. Then on the flip side, there's about 1500 maintainer scripts matching dpkg-statoverride found by binarycontrol.d.n. Since most have postinst and prerm and most are in all suites, that's about 250 packages. Of these, the vast majority only ever deals with canonical paths or paths unaffected by the /usr-merge. Checking all of these manually as a one-shot effort definitely sounds more plausible to me. To validate this claim (after having made a wrong one), I actually performed the analysis for unstable and found only five affected packages. I intend to move this forward by supplying the necessary patches. Changes needed: * fuse (queries only, can be duplicated now) * fuse3 (queries only, can be duplicated now) * ntfs-3g (queries only, can be duplicated now) * systemd-cron (needs to be updated when moving files) * yp-tools (needs to be updated when moving files) Nontrivially unaffected: * nfs-common (removes an aliased statoverride) Unaffected: * activemq * amavisd-new * apt-cacher-ng * asterisk * asterisk-config * autofs-ldap * ax25-apps * backuppc * balboa * biboumi * bird * bird2 * boinc-client * boxbackup-server * bucardo * ca-certificates * cado * ceph-base * ceph-common * ceph-mds * ceph-mgr * chrony * clamav-unofficial-sigs * cockpit-ws * corekeeper * coturn * courier-authdaemon * courier-authlib-ldap * courier-authlib-mysql * courier-authlib-postgresql * courier-base * courier-faxmail * courier-imap * courier-ldap * courier-mta * courier-pop * courier-webadmin * cron * cron-daemon-common * cubemap * cups * cups-daemon * cups-tea4cups * cups-x2go * cw * cyrus-common * davfs2 * davmail-server * dbus * deluged * dodgindiamond2 * dokuwiki * dovecot-core * durep * ejabberd * eviacam * exim4-base * exim4-config * fdutils * ferm * forked-daapd * fping * gammu-smsd * ganglia-monitor * ganglia-webfrontend * geki2 * geki3 * geoclue-2.0 * gerbera * glhack * gmetad * gnokii-cli * gnunet * graphite-api * graphite-carbon * graphite-web * gravitywars * groonga-httpd * groonga-server-common * gvmd * gweled * h2o * haserl * hplip * i2p * icinga2-common * icingadb * icingaweb2-common * ilisp * im * inadyn * incron * john * json2file-go * kea-common * kgb-bot * kismet * knot * libvirt-daemon-system * libx2go-server-db-perl * libzeroc-ice3.7 * lldpd * lmarbles * logdata-anomaly-miner * login-duo * lprng * lyskom-server * man-db * mandos * mandos-client * matrix-sydent * matrix-synapse * mgetty-fax * milter-greylist * minidlna * mlocate * mon * monsterz * mpd * mpd-sima * mpdscribble * muse * nagios4-cgi * nagios4-common * nagvis * nbsdgames * netdata-core * nethack-common * netselect * nginx-common * notus-scanner * nsca-ng-server * nsd * onak * open-infrastructure-compute-tools * opendkim * opendmarc * opendnssec-common * opensmtpd * openssh-client * opentracker * openvas-scanner * pacemaker-common * pawserv * pconsole * pdns-ixfrdist * phog * php-common * phpmyadmin * pkexec * plocate * pmount * polkitd * polkitd-pkla * postfix * powermanga * prayer * prometheus * prometheus-alertmanager * prometheus-apache-exporter * prometheus-bind-exporter * prometheus-blackbox-exporter * prometheus-haproxy-exporter * prometheus-ipmi-exporter * prometheus-mysqld-exporter * prometheus-node-exporter * prometheus-postfix-exporter * prometheus-postgres-exporter * prometheus-process-exporter * prometheus-pushgateway * prometheus-redis-exporter * prometheus-smokeping-prober * prosody * puppet-agent * puppetdb * puppetserver * pure-ftpd-common * pyracerz * qpsmtpd * radosgw * radvd * redis-sentinel * redis-server * redis-tools * roundcube-core * rtpengine-daemon * rtpengine-recording-daemon * samba-common * sasl2-bin * sendmail-bin * shibboleth-sp-utils * smstools * smtpprox-loopprevent * snort *
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi Andreas and Ralf, On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote: > > Moving the usertag to the qa namespace sounds like a good idea. > > I agree Thank you > Sounds like a good idea. However, I do not think that usertags support > a hierarchy of tags. So maybe different specific usertags with a common > prefix, like > > fileconflict-installation (error occurs when one tries to install two > packages togther) > fileconflict-upgrade (error occurs when upgrading, due to missing > breaks/replaces) > fileconflict-directory (error occuring due to /usr merge) Can either of you elaborate on the need to further classify the kind of conflict (file / directory / symlink / ...) or the kind of cause (installation / upgrade / ...)? Are you ok with explicitly excluding issues that only arise as a result of /usr-merge. These have a temporary cause and will vanish before too long. Due to the automatic bug filing that I hope to be doing, I need very precise tagging for them. Often times, it is initially not trivial to figure out whether a conflict only arises from installation or upgrades. Rather I propose to have a grab-bag tag for all of them. That allows us to move forward with less complexity and makes it easier to understand for everyone. Most of these issues result in an unpack error one way or another, but the symlink vs something else conflicts may result in unpack-dependent behaviour. I think we have consensus on using the debian-qa list, but I've seen file-overwrite and fileconflict-* as proposals with varying subclassification now. While we don't have a tag hierarchy on a technical level, Paul indicated that we may establish a hierarchy using processes. Using fileconflict makes it easy to establish a fileconflict-* subclassification later (by having the qa bot automatically add the super tag when it sees a sub tag). Is this convincing enough to move forward with the generic debian...@lists.debian.org usertag fileconflict rather than something more detailed? Is this also convincing enough to extend it to cover non-file conflicts or do you want a different tag for that? Should the tag also cover m-a:same file conflicts? I certainly won't object to doing a subclassification and I'm happy to add the subclass tags if doing so does not incur unreasonable implementation cost, but I don't want to participate in designing them nor updating existing tags. My need here is automatically ignoring detected issues that already are reported and the generic variant is sufficient for doing that. Helmut
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote: > Then I found trei...@debian.org using edos-file-overwrite. That latter > one seems like what I need here. Should we move it to the qa space and > drop the edos part? I suggest debian...@lists.debian.org usertags > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? I have scripts to automate usertags changes and watch weekly diffs. The QA copy runs from cron fixing some typos and my fork is modified and run when I notice any weird changes. The script can be used to easily perform moving and or renaming of usertags as needed here. https://salsa.debian.org/qa/qa/blob/master/data/cronjobs/usertags-fixes https://salsa.debian.org/pabs/qa/blob/master/data/cronjobs/usertags-fixes editor data/cronjobs/usertags-fixes mkdir tmp rsync --timeout=60 --recursive --delete rsync://bugs-mirror.debian.org/bts-spool-index/user/ tmp/all/ ./data/cronjobs/usertags-fixes --debug tmp -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hello, On Mon, Jul 17, 2023 at 10:35:24AM +0200, Andreas Beckmann wrote: > On 17/07/2023 07.16, Helmut Grohne wrote: > > Then I found trei...@debian.org using edos-file-overwrite. That latter > > one seems like what I need here. Should we move it to the qa space and > > drop the edos part? I suggest debian...@lists.debian.org usertags > > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? > > Moving the usertag to the qa namespace sounds like a good idea. I agree > And dropping the ancient edos prefix ... Yes. At the origin, the edos prefix was useful for us as the tool used to detect these bugs came from the edos project, but that project is over since a long time. And the tag has been used since then by others for tagging these kind of bugs discovered independently. So yes, time to simplify. > edos-file-overwrite has been used primarily for file-vs-file conflicts (as > these are the only ones detectable by analyzing .contents files) That was it's original target, and more specifically between packages in the same distro, but as Andreas explained that was extended by others to upgrading bugs: > We also didn't distinguish between file overwrites happening within a distro > (two packages in sid shipping the same file) and on upgrades (the file in > question moved between packages with insufficient Breaks+Replaces). Maybe we > should. Sounds like a good idea. However, I do not think that usertags support a hierarchy of tags. So maybe different specific usertags with a common prefix, like fileconflict-installation (error occurs when one tries to install two packages togther) fileconflict-upgrade (error occurs when upgrading, due to missing breaks/replaces) fileconflict-directory (error occuring due to /usr merge) Or something in this direction. -Ralf.
Re: usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
On 17/07/2023 07.16, Helmut Grohne wrote: Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? Moving the usertag to the qa namespace sounds like a good idea. And dropping the ancient edos prefix ... edos-file-overwrite has been used primarily for file-vs-file conflicts (as these are the only ones detectable by analyzing .contents files) IIRC you were looking also for other cases, e.g. file-vs-directory. Maybe we should use two tags in combination, the general file-overwrite and a more fine-grained one describing the actual problem even better. We also didn't distinguish between file overwrites happening within a distro (two packages in sid shipping the same file) and on upgrades (the file in question moved between packages with insufficient Breaks+Replaces). Maybe we should. There is also the case of files that shouldn't be shipped in any package (e.g. /usr/lib/python3/dist-packages/examples/README.txt), which usually shows up with a file-overwrite error if more than one package ships the file. IIRC I didn't tag these with the edos-file-overwrite usertag. (Such files are usually also reported to lintian to flag them as "overly generic filename", e.g. #947264) Is there some place where these tags are documented? Ideally some wiki page with links to the corresponding bts query to get the bug lists ... And information how these errors are searched for (semi-)automatically. Andreas
usertagging file conflicts [Was: Re: /usr-merge: continuous archive analysis]
Hi, On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## Usertagging bugs > > In order to avoid filing duplicates, I need a usertagging scheme for > bugs. Are there opinions on what user I should use for this? In the > simplest instance, I can use my DD login. Roughly speaking every issue > type shall translate to an individual usertag. Is there a common usertag > for undeclared file conflicts to reuse? I did not see any replies towards this aspect. I researched the situation and found that a longer while ago a...@grinser.de and later a...@debian.org used qa-file-conflict. I also discovered that Adreas uses debian...@lists.debian.org together with replaces-without-breaks, which is not what I'm looking for, but closely related. Then I found trei...@debian.org using edos-file-overwrite. That latter one seems like what I need here. Should we move it to the qa space and drop the edos part? I suggest debian...@lists.debian.org usertags file-overwrite. Otherwise, Ralf are you ok with me reusing your tag? What are the precise semantics of the tag? I imagine that it should only be filed against binary packages (one or more) and never with source packages. In case the causing package is known, it should be filed with the causing package and a version while other binary packages should be listed in affects. Otherwise, the bug should be filed against all involved binary packages. It is ok to group related conflicts by filing against multiple binary packages. These bugs should normally be release critical. These semantics allow machine consumption and facilitate avoiding duplicates in an automatic bug filing (to be agreed to). Does anyone have any objections to using this tag with these semantics? It would be most useful if other people filing such bugs would start using this usertag of course. :) I'm adding as possible metadata update at the end of this mail. It only handles conflicts involving possibly aliased paths though as those are my primary interest here. Helmut user debian...@lists.debian.org # android-libnativehelper/bullseye-backports vs android-libnativehelper-dev/bullseye usertags 1040323 + file-overwrite affects 1040323 + android-libnativehelper-dev # cadabra2/bullseye vs python3-notebook usertags 1036021 + file-overwrite affects 1036021 + python3-notebook # discodos/unstable vs mono-devel usertags 966115 + file-overwrite affects 966115 + mono-devel # firebird-utils/experimental vs firebird3.0-server usertags 1040321 + file-overwrite affects 1040321 + firebird3.0-server # kodi-addons-dev/bullseye-backports vs kodi-addons-dev-common/bullseye usertags 1040319 + file-overwrite affects 1040319 + kodi-addons-dev-common # occt vs oce mess usertags 1037067 + file-overwrite affects 1037067 + liboce-modeling-dev liboce-visualization-dev # rawloader usertags 1041299 + file-overwrite affects 1041299 + libplucene-perl graphicsmagick-imagemagick-compat # qt6-base-dev/experimental vs libqt6opengl6-dev usertags 1041300 + file-overwrite affects 1041300 + libqt6opengl6-dev # nex vs nvi usertags 1022957 + file-overwrite affects 1022957 + nvi # nfs-ganesha-ceph/bullseye-backports vs nfs-ganesha/bullseye usertags 1040362 + file-overwrite affects 1040362 + nfs-ganesha
Re: /usr-merge: continuous archive analysis
Hi Helmut, thanks for your continuious work on this! On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > To make matters worse, an upload to bookworm-backports > is immediately available to users and there is no migration that some > check (such as dumat) could hook into. there is NEW processing however and every package going into bookworm-backports needs to go through it... and granted, once it's in there no more NEW processing (unless $conditions), so this not perfect but it's more than nothing. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I’ve said it once, and I’ll say it a thousand times: If the penalty for breaking a law is a fine, then that law only exists for the poor. signature.asc Description: PGP signature
Re: /usr-merge: continuous archive analysis
On Wed, 12 Jul 2023 at 22:23:08 -0400, Theodore Ts'o wrote: > On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > > There is one major issue where I don't have a good answer: > > bookworm-backports. When this originally surfaced, Luca Boccassi > > suggested that we do not canonicalize in backports. That's easier said > > than done as the support for split-/usr will soon vanish from packages... > > ... detect whetther it is being > built on a distro version that might have split-/usr, or not I think it's important that we be clear about what does and doesn't need to be supported in each suite, because it's a bit confusing, and I think I can already see some of that confusion in this thread. For bullseye and older, there were two supported layouts, which we could call split-/usr and merged-/usr. In both of these layouts, it was the package's choice whether the canonical path for a "/usr-like" file inside the package's data.tar.* is in /usr (like /usr/bin/env) or not (like /bin/bash). In split-/usr, the physical path on disk matches the path that dpkg considers to be canonical. In merged-/usr, the aliasing symlinks like /bin -> usr/bin exist, so the physical path on disk is always in /usr, regardless of whether the canonical path is. For bookworm, as resolved in #978636, merged-/usr is officially the only layout that is supported. However, as resolved in #994388, we recommend that all packages in bookworm keep canonical paths in data.tar.* the same as in bullseye, for example /bin/bash. What we are now doing is trying to find a safe way to lift that restriction for trixie. Also, as resolved in #994388, we expect packages in bookworm to work at least minimally in a split-/usr environment, because the upgrade from bullseye to bookworm happens in an unspecified order and the system should work (at least well enough for recovery) at all points through the upgrade. In an effort to make sure that still happens, bookworm buildds still build packages in a split-/usr environment (because that way round has been observed to cause fewer bugs than building in a merged-/usr environment and installing in a split-/usr environment). For trixie and newer, the strategy Helmut proposes involves gradually changing the canonical path of all "/usr-like" files inside packages' data.tar.*, so that by the time we release trixie it is below /usr in all cases (for example /usr/bin/bash), which will result in the package only working as intended if the aliasing symlinks are in place. I think the question that Ted needs an answer to, for backportable packaging, is not actually whether the distro version has split-/usr as a supported configuration or not, but more like: whether it is safe or unsafe to make all /usr-like paths in data.tar.* be below /usr on this distro version. In bookworm or older, that is not safe; in trixie, our goal is that it becomes safe, and indeed recommended. (We are not there yet!) Because bookworm-backports is an extension of bookworm and users are expected to upgrade to bookworm before enabling bookworm-backports, split-/usr is not considered to be a supported situation there, so it's reasonable for packages that are outside the critical path for bootstrap and compilation to assume merged-/usr; but it is (probably) still not safe for those package versions to canonicalize all their /usr-like paths into /usr. > I had *one* > set of debian files that would successfully build on Debian stable, > Debian testing, Debian oldstable, Debian oldoldstable [etc.] This is sometimes a nice thing to be able to do, and we shouldn't break it for no reason, but it's easy for it to over-constrain the solution space to an extent that makes distro-wide changes harder or impossible. Intentionally keeping packaging files (especially d/rules) compatible with older distro versions comes with a risk of ossifying packaging and holding back adoption of desirable changes. For instance, I think we can see echoes of this in the way multiarch library paths have been best-practice in Debian for at least a decade, but unstable *still* has libraries in /usr/lib. (Perhaps it's time for some mass-bug filing or a Lintian check...) The main things that Debian delivers are the current stable release and the next stable release, and I think maximizing the quality of those should be our priority. smcv
Re: /usr-merge: continuous archive analysis
Hi Ted, On Wed, Jul 12, 2023 at 10:23:08PM -0400, Theodore Ts'o wrote: > For those packages that are likely to be backported, would ti be > possible provide some tools so that the package maintainers can make > it easy to have the debian/rules file detect whetther it is being > built on a distro version that might have split-/usr, or not, or > whether we the package needs to do various mitigations or not? Please allow me to go into a little more detail as to why we get into a problem for backports and then circle back to your question. I currently imagine (and this has been vaguely circulated on d-devel a number of times) to facilitate the canonicalization using debhelper. We have minor disagreements on how exactly that should work. Let me give my preferred version while keeping in mind that this is not yet consensus: debhelper gains a new addon. It could be called usrmerge or something. If you enable usrmerge, debhelper would perform the path canonicalization for you. Your dh_auto_install could install to canonical and aliased paths, but the .deb would be canonicalized. Thus, you can easily opt into it by saying Build-Depends: dh-sequence-usrmerge. We may also add this addon to a new compat level as we expect that most packages in trixie will need it. Thus we're changing it from opt-in to opt-out. While you can merge like that, a number of packages will notice that you can simplify your packaging by e.g. changing --prefix=/ to --prefix=/usr or something similar and doing that canonicalization at dh_auto_install time. In doing this, they loose the information about how files were previously being split to / and /usr. For instance systemd needs extra effort to support the split layout and that support is going to be deleted soon. I expect this to happen for most packages. And this is the part that makes backporting hard in a way that honours the moratorium for bookworm-backports. I'm sorry for not having considered the use case of using a single debian/ directory tree for multiple distributions and releases, but it is fairly obvious in hindsight. Is checking for the presence of usr-is-merged good enough for your case? What I imagine you doing here is generally supporting split-/usr in e2fsprogs (for as long as you want to support building e2fsprogs on any system that needs such support) and then telling debhelper to enable the usrmerge addon whenever you don't need to support split-/usr. A fairly obvious candidate check would be checking for the presence of usr-is-merged, but while bookworm always contains that, we effectively want it to support split-/usr to facilitate upgrades. Some of the mitigations require the addition of a usrmerge-support package whose preinst will unconditionally reject unmerged systems. Would that be a suitable condition? > The point is before we lift the freeze, perhaps we can provide some > tools that make it easier for package maintainer to only "make > split-/usr support vanish" conditionally, so as to make life easier > for people who are doing the bookworm and bullseye backports? If going with the debhelper addon and keeping split-/usr support in the particular package otherwise, the one backporting can simply pass --without usrmerge to dh and be done. If using the usrmerge-support package as condition (could even be done inside debhelper), that would become automatic. > I don't mind keeping some buster and bullseye and bookworm schroots > around, and doing test-builds of the packages I build, and then making > minor adjustments as necessary to make sure things still work. > Combined with some test automation so that we can test to see whether > a package about to be uploaded to bullseye-backports won't break on a > split-/usr machine, and this should be quite doable. The real problem I see with such backports is a different one though. Consider the case where we reorganize a package (move files between packages) during the trixie cycle. In the normal scheme of things we have this sequence: * bookworm v1: split-/usr + original file layout upgrade * trixie in progress v2: merged-/usr + original file layout upgrade * trixie in progress v3: merged-/usr + reorganized package upgrade * trixie in progress v4: merged-/usr + reorganize again That reorganization may trigger the need for applying a mitigation and the main plan is to only apply such mitigations as-needed. Now when you backport this, you'd revert the merged-/usr part, so instead you end up with this: * bookworm v1: split-/usr + original file layout upgrade * bookworm-backports v2~bpo: split-/usr (reverted) + original file layout upgrade * bookworm-backports v3~bpo: split-/usr (reverted) + reorganized once package upgrade * trixie v4: merged-/usr + reorganized again This upgrade sequence may require a different mitigation, because we swapped the order of canonicalization and reorganization. I have not yet come up with an actual test case where this breaks, so maybe I'm really wrong
Re: /usr-merge: continuous archive analysis
Hi Luca, On Thu, Jul 13, 2023 at 01:38:16AM +0100, Luca Boccassi wrote: > On Wed, 12 Jul 2023 at 14:35, Helmut Grohne wrote: > > "risky" ones from becoming practically relevant). There is one kind of > > issue that may be actionable right now and that's the class of "empty > > directory" issues. If you notice that such an empty directory actually > > is not necessary (which probably is the case in the majority of cases), > > please go ahead and delete it from your package[2] or a file a bug with > > a patch. Also, please declare Conflicts or Replaces as usual as some > > forms of undeclared file conflicts also show up in the analysis. Another > > thing that helps now is cleaning up really old and unversioned Replaces > > as those may result in false negative detections. ... > > [2] List of packages that *may* be actionable: fwupd, gcc-snapshot, > > gretl, lib32lsan0, libjte-dev, libmpeg3-dev, libswe-dev, libx32lsan0, > > pcp, pkg-config, pkgconf, pkgconf-bin, python3-expeyes, systemd > > Does this mean I can nuke that empty directory from the systemd > package right now, without waiting for the rest of your proposal to be > implemented? Thanks for asking. We have empty directories in binary packages in lots of cases. Some of them are there for some technical need. In other cases, the empty directory is a oversight and entirely unnecessary. I am fairly convinced that the lib*-dev packages shipping an empty /usr/lib/pkgconfig fall in that latter category and can delete their /usr/lib/pkgconfig at no loss of functionality. On the flip side, my understanding is that at least pkgconf and systemd ship their empty directories on purpose as intentional integration points and that these are not unused and should therefore not be deleted. So while dumat can tell whether a particular empty directory participates in a /usr-merge issue, it cannot tell you what the right action is. In some of the cases, the action is delete and that can happen at any time while in other cases the action is to protect them from accidental deletion, which is something we have to defer until there is consensus on the chosen mitigation. Helmut
Re: /usr-merge: continuous archive analysis
On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## No good solution for bookworm-backports > > There is one major issue where I don't have a good answer: > bookworm-backports. When this originally surfaced, Luca Boccassi > suggested that we do not canonicalize in backports. That's easier said > than done as the support for split-/usr will soon vanish from packages > ... Adding such intrusive changes to > bookworm-backports and pulled by a significant fraction of backports > sounds bad to me. The alternative here is that backporting will become a > lot harder as those performing backports would have to undo the > canonicalization. For those packages that are likely to be backported, would ti be possible provide some tools so that the package maintainers can make it easy to have the debian/rules file detect whetther it is being built on a distro version that might have split-/usr, or not, or whether we the package needs to do various mitigations or not? I've done that by hand, since for a while I was maintaining the debian directiry in e2fsprogs (yes, I know, bad bear, you're not supposed to do that), but one of the reasons why I did this is that I had *one* set of debian files that would successfully build on Debian stable, Debian testing, Debian oldstable, Debian oldoldstable, some random Ubuntu LTS versions, *and* Google's Prod-NG[1] variant. That's because I wanted to allow people to check out the latest version of e2fsprogs from the git tree, and build it on a variety of distro versions, even though e2fsprogs upstream had added some new binaries, or some new config files, since Debian oldoldstable had been released. [1] https://marc.merlins.org/linux/talks/ProdNG-LinuxCon2013/ProdNG.pdf I haven't kept up with it, since it's not really needed any more (Google has since migrated away from ProdNG to something else, and I stopped caring about Ubuntu LTS :-), but the hardest part was dealing with various different versions of debhelper. The point is before we lift the freeze, perhaps we can provide some tools that make it easier for package maintainer to only "make split-/usr support vanish" conditionally, so as to make life easier for people who are doing the bookworm and bullseye backports? I don't mind keeping some buster and bullseye and bookworm schroots around, and doing test-builds of the packages I build, and then making minor adjustments as necessary to make sure things still work. Combined with some test automation so that we can test to see whether a package about to be uploaded to bullseye-backports won't break on a split-/usr machine, and this should be quite doable. Of course, this may be more effort than people are willing to do - Ted
Re: /usr-merge: continuous archive analysis
On Wed, 12 Jul 2023 at 14:35, Helmut Grohne wrote: > > Hi, > > I'm doing yet another /usr-merge thread even though we already have too > many, I know. > > The first one was about general discussion and problem analysis. In that > first thread, I posted a number of scripts for analyzing problems and > snapshot analysis data. In that second thread, we tried to gather > consensus around some of the views expressed. > > # Continuous monitoring for problems > > This thread hopefully becomes more of a FYI than a discussion. I've > turned those hacky scripts into some Python code that continuously (4 > times a day) analyzes the archive for some of the problems summarized in > DEP17. Interested parties may find the code at > https://salsa.debian.org/helmutg/dumat. The results of the analysis[1] > (around 2000 lines) are updated at > https://subdivi.de/~helmut/dumat.yaml. While it says "issue" there, most > of them are *not* actionable right now. Please don't panic. Keep in mind > that the moratorium is still active (and that it prevents any of the > "risky" ones from becoming practically relevant). There is one kind of > issue that may be actionable right now and that's the class of "empty > directory" issues. If you notice that such an empty directory actually > is not necessary (which probably is the case in the majority of cases), > please go ahead and delete it from your package[2] or a file a bug with > a patch. Also, please declare Conflicts or Replaces as usual as some > forms of undeclared file conflicts also show up in the analysis. Another > thing that helps now is cleaning up really old and unversioned Replaces > as those may result in false negative detections. > > What does dumat not detect? > * DEP17-P4: Disagreeing alternatives are not a problem as long as we >don't canonicalize alternatives (DEP17-M13). I think we can defer >this without causing extra pain. > * DEP17-P5: dpkg-statoverrides not matching the files shipped. >Possibly, I can extend dumat to cover unconditional statoverrides. > * DEP17-P8: Filesystem bootstrap. The test matrix is really small, so >we'll probably notice when it gets broken. > * DEP17-P9: Loss of aliasing symlinks. We can reliably address this >centrally e.g. via DEP17-M4. > > # A rough outlook > > Let me give a rough idea on how I would like to move forward with this > and hope you agree with it. > > For one thing, we need an agreement on the mitigations that we apply. > Except for the bootstrapping aspect, this seems relatively clear. That > discussion will likely continue and conclude eventually. > > ## A proposed process > > Some of the mitigations are non-trivial to implement and cannot be done > e.g. by the janitor, but the dumat.yaml file tells us that the number > of occasions where we need them will be fairly low. It's the exceptional > case that goes wrong badly. Since the matter is fairly complex and since > breakage is rare, I would like to move forward in a way where we do not > ask maintainers to pay attention to /usr-merge problems proactively, > but reactively. That works with two mechanisms: > * We generally ask maintainers to upload some classes of changes to >experimental first. Those include: > + Moving files from / to /usr. > + Moving files between packages. > + Changing diversions. > + Changing path-based trigger interest. > + When in doubt. > * You allow me to turn that dumat.yaml tool into an automatic rc bug >filing service. > The big benefit of this approach is that it lifts the mental load of the > matter from individual maintainer's brains. You have a simple rule (use > experimental when in doubt) and if your change poses any issue, you > receive an rc bug (for that experimental package if you uploaded there > or possibly for sid where it acts as migration blocker). My expectation > is that such bugs are rare events. If you don't receive an rc bug within > two days, assume that your change is fine. > > I am aware that having an automatic bug filing service with no human > supervision (ahead of filing) is something we never had before. Much > less for rc bugs. Before enabling this, you definitely want to see a bug > template. Are there general objections to this idea? I already talked to > Paul Gevers and he sees this as the preferred interface to implement a > migration blocker. We already have piuparts/autopkgtest automatically blocking migration, and some lintian checks even block NEW uploads, so this sounds perfectly fine to me. > ## Usertagging bugs > > In order to avoid filing duplicates, I need a usertagging scheme for > bugs. Are there opinions on what user I should use for this? In the > simplest instance, I can use my DD login. Roughly speaking every issue > type shall translate to an individual usertag. Is there a common usertag > for undeclared file conflicts to reuse? > > # Other aspects > > ## Informative MBF > > When I discussed this in Hamburg, there was a request to
Re: /usr-merge: continuous archive analysis
Hi,
Quoting Helmut Grohne (2023-07-12 15:34:38)
> This thread hopefully becomes more of a FYI than a discussion. I've turned
> those hacky scripts into some Python code that continuously (4 times a day)
> analyzes the archive for some of the problems summarized in DEP17. Interested
> parties may find the code at https://salsa.debian.org/helmutg/dumat. The
> results of the analysis[1] (around 2000 lines) are updated at
> https://subdivi.de/~helmut/dumat.yaml.
if you (like me) nearly didn't click that link because the number 2000 sounds
scarily large, don't be scared:
$ curl --silent https://subdivi.de/~helmut/dumat.yaml \
| python3 -c 'import
yaml,sys;print("\n".join(yaml.safe_load(sys.stdin).keys()))' \
| wc -l
92
So these 2000 lines describe just 92 binary packages from 77 source packages.
Attached is the dd-list output for the above.
Thanks!
cheers, josch"Adam C. Powell, IV"
oce (U)
A. Maitland Bottoms
airspyhf (U)
airspyone-host
bladerf
hackrf
libiio
libmirisdr
libosmosdr
rtl-sdr
Adrian Knoth
libffado (U)
Alessio Treglia
libnjb
Andrea Pappacoda
opensysusers
Andreas B. Mundt
libticables (U)
Andrej Shadura
pkgconf
Andrew Pollock
isc-dhcp (U)
Android Tools Maintainers
android-platform-tools
Anuradha Weeraman
ksh93u+m
Arne Bernin
libfreenect (U)
Bernhard Schmidt
mediastreamer2 (U)
CFEngine Team
cfengine3
Chris Halls
libreoffice (U)
Chris Hofstaedtler
util-linux (U)
Christoph Berg
hamlib (U)
Christoph Martin
cfengine3 (U)
nfs-ganesha (U)
Damyan Ivanov
firebird3.0
firebird4.0
Daniel Baumann
bfh-metapackages
nvme-cli
open-infrastructure-compute-tools
open-infrastructure-storage-tools
progress-linux-metapackages
zutils
Debian BOINC Maintainers
boinc
Debian Ecosystem Init Diversity Team
libpam-elogind-compat
Debian EFI
fwupd
Debian Electronics Packaging Team
libsigrok
Debian GCC Maintainers
gcc-13
gcc-snapshot
Debian Go Packaging Team
libpod
Debian Go Packaging Team
golang-github-blynn-nex
Debian Hamradio Maintainers
airspyhf
hamlib
Debian ISC DHCP Maintainers
isc-dhcp
Debian LibreOffice Maintainers
libreoffice
Debian Med Packaging Team
eegdev
Debian Mono Group
mono
Debian Multimedia Maintainers
kodi
libffado
libmpeg3
openni2
Debian OCaml Maintainers
ocaml-afl-persistent
Debian PhotoTools Maintainers
libgphoto2
Debian Printing Team
hplip
Debian Python Team
discodos
jupyter-notebook
Debian QA Group
nvi
powerman
Debian Science Maintainers
libticables
oce
opencascade
Debian Security Tools
cryptsetup-nuke-password
Debian systemd Maintainers
systemd
Debian sysvinit maintainers
orphan-sysvinit-scripts
Debian VoIP Team
mediastreamer2
Denis Barbier
oce (U)
Dimitri John Ledkov
what-is-python (U)
Dirk Eddelbuettel
gretl
Dmitry Smirnov
libpod (U)
Ervin Hegedus
hamlib (U)
Felipe Sateler
systemd (U)
Felix Lechner
mediastreamer2 (U)
Ferenc Wágner
libgphoto2 (U)
FingerForce Team
libfprint
Francois Marier
molly-guard (U)
Free Ekanayaka
libffado (U)
Frédéric Bonnard
rear
Georges Khaznadar
expeyes
Gianfranco Costamagna
boinc (U)
llvm-toolchain-snapshot (U)
Gordon Ball
jupyter-notebook (U)
Guo Yixuan (郭溢譞)
boinc (U)
Gürkan Myczko
cadabra2
Ian Jackson
libpam-elogind-compat (U)
IOhannes m zmölnig (Debian/GNU)
libmpeg3 (U)
Jo Shields
mono (U)
Jochen Sprickerhof
openni2 (U)
Johannes Tiefenbacher
discodos (U)
John Scott
open-ath9k-htc-firmware
Jonas Meurer
cryptsetup-nuke-password (U)
Jonathan McDowell
libsigrok (U)
Josh Triplett
molly-guard (U)
Julien Puydt
ocaml-afl-persistent (U)
Jérôme Charaoui
puppet-agent (U)
Jörg Frings-Fürst
sane-backends
Ken McDonell
pcp (U)
Kilian Krause
mediastreamer2 (U)
Kurt Kremitzki
opencascade (U)
Laszlo Boszormenyi (GCS)
fuse3
LLVM Packaging Team
llvm-toolchain-snapshot
Lorenzo Puliti
runit
Luca Boccassi
systemd (U)
Ludovic Rousseau
libnfc (U)
Ludovico Gardenghi
molly-guard (U)
Marc Haber
molly-guard (U)
Marco d'Itri
systemd (U)
Marco Trevisan
libfprint (U)
Mario Limonciello
fwupd (U)
Mark Hindley
libpam-elogind-compat (U)
Mark Renouf
libfreenect (U)
Martin Pitt
systemd (U)
Matthew Vernon
orphan-sysvinit-scripts (U)
Matthias Klose
what-is-python
Matthias Klose
gcc-13 (U)
gcc-snapshot (U)
Matthias Klumpp
fwupd (U)
Michael Biebl
systemd (U)
Michael Gilbert
isc-dhcp (U)
Mirco Bauer
mono (U)
Nathan Scott
pcp (U)
Nicolas Bourdaud
eegdev (U)
libfreenect
Nobuhiro Iwamatsu
libnfc
openni2 (U)
PCP Development Team
pcp
Petter Reinholdtsen
libmpeg3 (U)
Philippe Deniel
nfs-ganesha
Puppet Package Maintainers
/usr-merge: continuous archive analysis
Hi, I'm doing yet another /usr-merge thread even though we already have too many, I know. The first one was about general discussion and problem analysis. In that first thread, I posted a number of scripts for analyzing problems and snapshot analysis data. In that second thread, we tried to gather consensus around some of the views expressed. # Continuous monitoring for problems This thread hopefully becomes more of a FYI than a discussion. I've turned those hacky scripts into some Python code that continuously (4 times a day) analyzes the archive for some of the problems summarized in DEP17. Interested parties may find the code at https://salsa.debian.org/helmutg/dumat. The results of the analysis[1] (around 2000 lines) are updated at https://subdivi.de/~helmut/dumat.yaml. While it says "issue" there, most of them are *not* actionable right now. Please don't panic. Keep in mind that the moratorium is still active (and that it prevents any of the "risky" ones from becoming practically relevant). There is one kind of issue that may be actionable right now and that's the class of "empty directory" issues. If you notice that such an empty directory actually is not necessary (which probably is the case in the majority of cases), please go ahead and delete it from your package[2] or a file a bug with a patch. Also, please declare Conflicts or Replaces as usual as some forms of undeclared file conflicts also show up in the analysis. Another thing that helps now is cleaning up really old and unversioned Replaces as those may result in false negative detections. What does dumat not detect? * DEP17-P4: Disagreeing alternatives are not a problem as long as we don't canonicalize alternatives (DEP17-M13). I think we can defer this without causing extra pain. * DEP17-P5: dpkg-statoverrides not matching the files shipped. Possibly, I can extend dumat to cover unconditional statoverrides. * DEP17-P8: Filesystem bootstrap. The test matrix is really small, so we'll probably notice when it gets broken. * DEP17-P9: Loss of aliasing symlinks. We can reliably address this centrally e.g. via DEP17-M4. # A rough outlook Let me give a rough idea on how I would like to move forward with this and hope you agree with it. For one thing, we need an agreement on the mitigations that we apply. Except for the bootstrapping aspect, this seems relatively clear. That discussion will likely continue and conclude eventually. ## A proposed process Some of the mitigations are non-trivial to implement and cannot be done e.g. by the janitor, but the dumat.yaml file tells us that the number of occasions where we need them will be fairly low. It's the exceptional case that goes wrong badly. Since the matter is fairly complex and since breakage is rare, I would like to move forward in a way where we do not ask maintainers to pay attention to /usr-merge problems proactively, but reactively. That works with two mechanisms: * We generally ask maintainers to upload some classes of changes to experimental first. Those include: + Moving files from / to /usr. + Moving files between packages. + Changing diversions. + Changing path-based trigger interest. + When in doubt. * You allow me to turn that dumat.yaml tool into an automatic rc bug filing service. The big benefit of this approach is that it lifts the mental load of the matter from individual maintainer's brains. You have a simple rule (use experimental when in doubt) and if your change poses any issue, you receive an rc bug (for that experimental package if you uploaded there or possibly for sid where it acts as migration blocker). My expectation is that such bugs are rare events. If you don't receive an rc bug within two days, assume that your change is fine. I am aware that having an automatic bug filing service with no human supervision (ahead of filing) is something we never had before. Much less for rc bugs. Before enabling this, you definitely want to see a bug template. Are there general objections to this idea? I already talked to Paul Gevers and he sees this as the preferred interface to implement a migration blocker. ## Usertagging bugs In order to avoid filing duplicates, I need a usertagging scheme for bugs. Are there opinions on what user I should use for this? In the simplest instance, I can use my DD login. Roughly speaking every issue type shall translate to an individual usertag. Is there a common usertag for undeclared file conflicts to reuse? # Other aspects ## Informative MBF When I discussed this in Hamburg, there was a request to actively reach out to affected maintainers by sending a minor bug for every source package that is somehow involved. The bug would ask maintainers to move their files from / to /usr, how to do so, the need to do this via experimental first and the chances of getting an rc bug in the process. Do people who have not been to Hamburg Reunion 2023 confirm this? ## No good solution for
