On Mon, 19 Jul 2021 03:36:59 +0200, Guillem Jover <guil...@debian.org> wrote: >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…
In an ideal world, would the package manager not be a service utility to SUPPORT policy and adapt to changing environment contitions instead being a showstopper for innovation? Who is the dpkg maintainer to challenge the decisions of the entire project? I fully understand that there is only ONE dpkg maintainer, but a utility THIS central to the entire ecosystem not being team maintained is a HUGE part of the problem. And no, I cannot help and no, you wouldn't want me to write a single line of code in a package THIS central. >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. Would it not be dpkg's job to work around these flaws? It's not that every other component of a Debian system are perfect. >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.). I must be missing some thing, but isn't it the experienced admins facing reinstalls of vital systems when we finally move to a completely merged /usr, because these usually currently have /usr on a dedicated mountpoint? >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. :/ on both sides of the conflict, yes. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
