On Thu, 2021-07-15 at 10:13:47 +0100, Luca Boccassi wrote: > As it has been said and written many times already, in reality this is > not broken by design at all and in fact it is the only successful > strategy that has been deployed by other distros - it's what is being > called merged-usr-via-moves-and-symlink-farms that is broken. We can > say this with certainty because both approaches have been tried, so > there's actual real-world data to look at. Just go look at the absolute > mess that Suse got themselves into by following that solution - a 10- > years-long massive half-done-never-finished headache that took an > inordinate amount of work to back out of, and move to the actual > working solution that everybody else are using - merged-usr-via- > aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple > transition using merged-usr-via-aliased-dirs, and that was the end of > it.
Yes, a single (a couple!?) data point(s) of a strategy used in another unrelated distribution, with completely different packaging stacks and ecosystems, which was done very poorly, has been presented repeatedly. I'm not sure why that has much value TBH. The above seems to also be confusing how and if a design has been deployed, with its inherent (short and long term) properties. A badly performed *deployment* for a better design does not make its properties bad, in the same way that *deploying* a flawed design faster does not make its properties better… What I've also said multiple times, is that merged-usr-via-moves-and-symlink-farms could have been implemented in a fully automated way, by debhelper, w/o requiring any maintainer scripts, all with full cooperation and managed by dpkg, with .debs shipping actual tracked pathnames, if it had not been for the mess required by merged-usr-via-aliased-dirs. :/ > Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not > suffer from. So what? It is perfectly normal as it's software and all > softwares have bugs. They could be fixed, worked around, or ignored, > like all other bugs. If by "very minor bugs" you mean that f.ex.: * dpkg, dpkg-divert, or update-alternatives are unable to detect file conflicts and thus might allow silent overwrites of random stuff on disk, * when moving files across packages and across aliased directories, these pathnames might end up disappearing depending on the unpack order, * dpkg-deb -x on the root directory (yes, people use this to recover systems) with any .deb that contains files on real directories under «/», will replace the symlinked directories with real ones, then, yes, I guess "very minor" indeed. But then I completely object to this being classified as bugs in dpkg, as this has been shoved in disregarding that dpkg does *not* support this, and it would require new *features* to be implemented, so this "transition" is founded on assuming features that do not exist, or completely going behind dpkg's back, which sounds great I guess… The problem in general is that this layout introduces unreliability and silently induced breakage stemming from this flawed filesystem layout, which is going to affect the people that are going to benefit the less from its properties, and are the less experience to deal with it. I've tried to update the <https://wiki.debian.org/Teams/Dpkg/MergedUsr> with more explicit information, in case some people might have missed that from previous instances of this discussion, and added an initial table of properties for both proposals, to avoid cluttering and repeating it on the list, and to ease updating it. We do actually have experience with "an aliased" layout from symlinked /usr/share/doc/ directories, where those are for optional/removable parts of the filesystem, and the symlinks are even known and managed by dpkg. And those have been a major and constant source of packaging bugs. And here we are getting the project installing by default systems that are fighting the packaging system and going on its back, to enable a filesystem design layout mostly experienced admins will benefit from in very special deployment conditions, where final users can very easily suffer from its introduced unreliability (from 3rd-party repos or locally built packages, etc, f.ex.). Because the above has been brought up before and the proponents are well aware of these, I'm afraid at this point the only thing that comes to mind is negligence, TBH. :/ But *shrug*, have at it, I'm tired of the continued and complete disregard of the unreliability issues and subversion of the packaging system, which are supposed to be pillars of our project, every single time. I just replied so that people that might not want to be forced into this stuff know that there's going to be a way out. Regards, Guillem
