On Dec 31, Russ Allbery <r...@debian.org> wrote: > >> ACK. Sometimes upstreams doing really stange things (maybe because they > >> dont have any package management in mind), that should be fixed. If > >> upstream doesnt do those fixes, distros have to catch in. > Sometimes, I think Red Hat makes some of these design decisions because > RPM's handling of configuration files sucks. If it had always behaved > like dpkg, I wonder if they wouldn't use designs that honor configuration > files somewhat more. This has been my conclusion as well. And an ever bigger problem is that Red Hat just does not support upgrading to the next major release and so they choose to not care about lots of issues which are important to us.
> This, however, is a really good point, and is the thing that keeps running
> through the back of my head reading this thread. There seems to be a lot
> of sentiment that people wish udev (in particular) would work differently
A few people have been wishing for udev to work differently since it was
introduced in 2004. The major problem with these people is that they
usually do not understand how udev works, so they cannot propose
plausible alternative solutions, nor they have ever followed upstream
development, so they are unaware of the design choices and requirements
which lead to the current implementation.
I think it is obvious that so far I was right and they were wrong, since
they never actually proposed valid alternative solutions and my design
choices about how udev is integrated in Debian have been validated by
time and by adoption by other distributions.
(At least, before upstream drank the systemd kool aid.)
So we could waste a lot less time arguing over the inevitable if people
would accept that I tend to be right. :-)
> Note that Steve's point, namely that he (if I'm reading him right) thinks
> that the upstream changes are being overstated and that upstream's
> direction isn't actually going to cause problems for us, is an entirely
> separate one and not something I'm addressing in the above. And is
> certainly something to explore before we start arguing over who's going to
> fork something that may not be an issue at all.
Unsurprisingly, this is not a black or white issue: there are many
different issues in different parts of the stack and with different
levels of complexity.
In some cases I have been able to keep old code around (e.g. to support
older kernels than upstream did), but in others it is intrinsecally
impossible (e.g. when udev needs to IMPORT{} data from something which
lives in /usr).
--
ciao,
Marco
signature.asc
Description: Digital signature
