Re: from / to /usr/: a summary
"Bernhard R. Link" <email@example.com> writes:
> * Russ Allbery <firstname.lastname@example.org> [111231 18:41]:
>> This isn't about the package. It's about the *software*, the part that
>> we generally use from upstream as much as possible because asking
>> people to be both upstream and the Debian package maintainer is
>> generally too much work for one person or even a small packaging team.
> If the maintainer refuses patches and only wants to fix brokeness if
> someone does a full blown upstream fork then this is a maintainer issue.
I think this discussion is getting hopelessly muddled by excessive use of
sweeping statements like this. I can't tell from this response whether
you just disagree with Marco that the changes required will be substantial
and ongoing, or whether you think that Marco should be maintaining
substantial and ongoing patches himself as part of some obligation to the
project for having the title of udev maintainer, or something else. And
that lack of clarity just makes for more pointless arguments.
Semantically, *any* patch is a fork of a sort. Practically, small patches
involve small amounts of ongoing work and therefore become a different
sort of thing than a real fork. A real fork is required if the patches
become substantial, impact core functionality, and pose significant merge
issues. But there's no clear distinction.
My understanding of Marco's position is that the changes to udev that
people are objecting to (undermining the ability to mount only / and not
/usr at early boot, and using configuration overlays or replacements in
/etc with package files in /lib) are the sort of changes that cannot be
reversed with a simple patch that Marco can easily maintain on an ongoing
basis. That even if the current complexity is low, he believes it will
This is an ENTIRELY REASONABLE thing for a maintainer to say, and an
entirely reasonable thing for a maintainer to not want to get involved
in. I daresay it's likely you've done the same yourself for some wontfix
divergence from upstream with one of your packages. I know I certainly
have with mine. Packaging resources are limited, and maintaining
permanent divergence from upstream is a lot of hard work.
Please, don't try to paint this position as some sort of dereliction of
duty in order to score rhetorical points. It doesn't get us anywhere.
If you think Marco is wrong in his estimation of the level of effort
required, *that* is useful information, particularly if it's backed up
with a concrete analysis (which would involve research into what the
changes entail and what the udev upstream has said). That's a good
discussion to have. But just hammering on Marco because you don't like
the upstream direction of the package (at least as he understands it) and
you want him to single-handedly stop it is pointless and needlessly
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>