Re: Go (golang) packaging, part 2
* Russ Allbery <rra@debian.org> [130201 21:38]:
> > If you want bleeding edge, then you are not a normal user and you
> > certainly aren't a system administrator that wants to keep a controlled
> > system they can reproduce.
>
> Speak for yourself. I've been a system administrator for twenty years,
> and sometimes I have to deploy bleeding-edge code in order to accomplish a
> particular task. You can do that in ways that also give you a
> reproducible system.
>
> Using Debian packages is a *means*, not an *end*. Sometimes in these
> discussions I think people lose sight of the fact that, at the end of the
> day, the goal is not to construct an elegantly consistent system composed
> of theoretically pure components. That's a *preference*, but there's
> something that system is supposed to be *doing*, and we will do what we
> need to do in order to make the system functional.
>
> Different solutions have different tradeoffs. Obviously, I think Debian
> packages are in a particularly sweet spot among those tradeoffs or I
> wouldn't invest this much time in Debian, but they aren't perfect. There
> are still tradeoffs. (For example, Debian packages are often useless for
> research computing environments where it is absolutely mandatory that
> multiple versions of any given piece of software be co-installable and
> user-choosable.)
Of course there are trade-offs. For every rule, as sensible it might be,
there can be a need great enough to ignore it. Using software not
properly packaged is not so different from modifying files in /usr/lib
from the distribution, compiling passwords or other hardcoded stuff
directly into programs, using binaries you have no source of or even
using those and patching the binary or many many other things you can do
and sometimes you have to do.
That there are no guidelines that are absolute and that may not be
better ignored in some cases does not change that in general they
show a useful path that leaving without a good reason is no good idea.
And a "only use distro packaged software" is a very useful guideline.
There are so many advantages in this that "you cannot get this with
distro packages" is a very good argument against anything you cannot
get this way. There will always be a case where there can be a more
important argument pushing the scales in the other direction, but at
the end of the day, the normal system administrator wants one package
management tool for all their software (or at least as few as possible)
and as few copies/different versions of common code (aka libraries,
modules, ...) around as possible. And most of the features for
developers are just additional nightmares for the administrator.
Bernhard R. Link
Reply to: