Re: Go (golang) packaging, part 2
"Lennart Sorensen" <lsorense@csclub.uwaterloo.ca> writes:
> On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote:
>> I hope that's not generally true, because that would be horribly
>> depressing. I don't believe that's true of the Perl community in
>> general. It's certainly not true of the C or Java community!
> Not all C libraries are distributed from one central site and they
> certainly don't expect you to use a central package installation system.
So much more the shame for C. Those are *improvements* that Perl came up
with (well, actually, that the TeX community came up with and Perl copied)
that made the ecosystem much nicer.
> I personally consider Java a bad joke that won't go away.
Look, if other people like something and use it heavily, that's probably
because it solves their problems. Saying that it doesn't solve *your*
problems, or even that it creates problems for you, does not change the
fact that it solves *their* problems.
I have some personal experience with Java on both the systems
administration side and on the developer side. It's an awful language for
deployment, and it's a great language to write code in, with an incredibly
rich ecosystem of well-tested and reliable components for nearly anything
you'd want to do. In particular, it is far better at APIs and code
boundaries than Perl is, and therefore scales to large teams of developers
more naturally and more easily than Perl does. And I say this as someone
who loves Perl and maintains core Perl modules.
The same Java infrastructure that makes it so incredibly painful to
construct a consistent system with separated and separately-upgradable
parts makes it a wonderful system in which to develop and to create
applications with reliably consistent behavior. Particularly if, as is
the case in a depressing number of environments, the system administrators
are in some other group from the developers, they're not allowed to
coordinate, and the system administrators have all sorts of rules and
restrictions the developers have to go through to update anything in
production.
You talk about reproducible systems as one of your primary goals. Well,
that's exactly why Java does those things that make it such a pain in a
Debian context. If you bundle together all the exact JARs that were
tested and known to work and don't change any of them, you get exactly
that: a reproducible system that works exactly like it did in the test
environment. You of course also have a system that has some real problems
when it comes time to do security upgrades, and one that tends to be very
difficult to upgrade to the latest version of the JARs when you need some
new feature. But those are *tradeoffs*. That is not an absolute flaw in
Java.
The flaws in Java are more obvious in a devops environment. Most sites
aren't devops. If you're in a traditional "develop, test, and throw it
over the fence to the production guys" shop, Java's ability to roll up
your application into one file that is completely self-contained is a
*godsend*.
You may feel that all non-devops shops should get the religion. I'd even
agree with you. But all the stuff we're talking about are artifacts that
exist in the real world and have to deal with how that world currently
works, not how we want it to work at some theoretical point in the future.
> If I want something updated that is newer than what debian provides,
> then I will make the .deb myself. I want everything consistently
> installed.
Sure. Me too. I've also been making Debian packages for years, so this
is a matter of an hour or two of work, or less if I don't care about doing
it properly.
> I like my system to stay working and maintainable. I still have one
> system that was installed with Debian 2.1, and upgraded ever since and
> is still doing fine. You don't generally get there by taking shortcuts
> that seem convinient now, even though long term they are a bad idea.
Sure. I have that religion too.
The other way that you don't get to having a system that's been
continuously upgraded from Debian 2.1 is if you got fired somewhere around
Debian 3 because you couldn't deploy things fast enough for your boss, who
didn't give a shit about whether things were in Debian packages or not.
Tradeoffs.
> Making a debian package is generally very easy, so if you need something
> on your system, make a package for it.
I would love this to be the case. It just isn't.
*I* find it easy. I know lots of other people who find it easy. And, in
fact, we make doing this mandatory within my group. But because we made
it mandatory, I've trained a lot of sysadmins and developers in how to do
this. I've seen the problems they ran into, I've helped them out of blind
corners, I've cleaned up some of the messes, and I've helped them find
better tools.
It's not easy. It's really not easy for quite a few people.
I do think it pays off in the long run. If one has the luxury of a long
run, teaching people proper packaging is great. In the short run, for at
least the first few packages people make, it is almost certainly the case
that they would have gotten their problem solved and their system deployed
much faster if they had not tried to make a proper package.
I'm a long-run guy too. I love to focus on the long run. But it's a
luxury and a privilege to be able to do that. Projects, deadlines, and
management priorities normally don't much care about the long run. That's
something that we often have to teach the people who are pushing to get
something done, and sometimes that sticks, and sometimes that doesn't.
As upstream, I want my software to feel right, to feel elegant and
comfortable, to people who want to take the long-run approach and do
things right. But I also want my software to be usable by people who have
a crash project that has to be done by tomorrow and who are reaching
desperately for my software because it does something that's mandatory for
that project and they don't have time to figure out another way to do it.
If that means that using cpan install gets them working software faster,
then three cheers for cpan install!
> For cpan there is even dh-make-perl. The solution then is to make
> equivelant scripts for other languages. The solution is NOT to use some
> other package installation system.
dh-make-perl is great, don't get me wrong, but the problem with this sort
of automation is that it works 90% of the time and then 10% of the time
there's some weird oddity or corner case. And if you don't know anything
about Debian packaging and you don't know how any of the pieces work, if
you only know how to use the automated tool, then when you hit that 10%
case, you are completely lost.
That's a demoralizing place to be. That's when people switch back to cpan
install, which is a rather thinner wrapper around a bunch of commands one
can run manually, and which the upstream whose code you're trying to
deploy probably already understands and can help you with.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: