[csw-maintainers] commentary on shared library naming proposal

Philip Brown phil at bolthole.com
Tue Nov 16 18:56:55 CET 2010


On 11/16/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Tue Nov 16 12:00:41 -0500 2010:
>
>> "The benefit " is supposed to be for the user, not the maintainer OR
>> the release manager. :)
>
> Sebastian made a valid point in this regard.  Other than a few extra
> http fetches, they typically won't notice (in any meaningful sense)
> whether they grab a few extra packages or not.
>
> What they _will_ notices is nicer transitions of packages as
> _maintainers_ have a lot more freedom to upgrade packages gradually
> instead of as a big lump.

> This should result in a better user experience overall.

There isnt a single "ALWAYS TRUE" method for this. Certainly, there's
a "usually true". but not always. That's why the debian policy is the
way it is.
They've had years more experience dealing with this issue than than us, right?
And they explicitly call out that it is just fine to have a single
package, that itself contains multiple shared libs, rather than
splitting out the shared libs into individual packages.
(if the libs are always going to be upgraded together)

The "libcups" stuff pending in newpkgs, is actually a perfect example
of this. When will a user EVER want to upgrade them separately? Or
even a maintainer?
Come on now.. you cant honestly say either a user Or a maintainer will
deliberately want to ever upgrade them separately.
A maintainer will just grab the latest release of cups, run a make,
and release the full set of packages that are generated.

These days, even when I suggest to a maintainer, "hey, there's a
problem with this one package in your (set of 4, 6,8), but the rest
are fine"... no-one ever gives me back the one package. They dump a
full set on me again.


Seems like it's this sort of reason why debian, and pretty much any
other distro on the planet, only has a single "libcups" package,
rather than 6 separate ones for each of the shared libs in there.


More information about the maintainers mailing list