
Who helps your Linux distribution run smoothly? Thank a packager today - Tsiolkovsky
http://opensource.com/business/14/2/thank-a-linux-packager-today
======
zdw
If you're a developer, try to package your own things for the distros you care
about. And accept patches that fix packaging issues. Think about how much
easier your ops friends, and the continuous integration systems and similar
will have it if all they have to do is run an "apt get" or "port install" to
get a fully built version of your code.

Things that help:

[http://fedoraproject.org/wiki/How_to_create_an_RPM_package](http://fedoraproject.org/wiki/How_to_create_an_RPM_package)

[https://wiki.debian.org/IntroDebianPackaging](https://wiki.debian.org/IntroDebianPackaging)

[http://guide.macports.org/chunked/development.creating-
portf...](http://guide.macports.org/chunked/development.creating-
portfile.html)

[http://www.openbsd.org/faq/ports/guide.html](http://www.openbsd.org/faq/ports/guide.html)

[http://www.netbsd.org/docs/pkgsrc/creating.html](http://www.netbsd.org/docs/pkgsrc/creating.html)

~~~
massysett
Shouldn't packaging be left to each distributor's experts? As a developer of
software you're an expert in whatever your software does--web server,
calculator, compiler, whatever. There is no way you can be an expert in your
software's functionality and in packaging, especially for more than one
distribution.

I'm always wary of installing packages not provided by my distribution, just
because I have more faith that my distribution's packagers know how to package
and they are more likely to use QA processes that will catch packaging bugs.
I'd rather compile from source than install third-party packages; I can make
my own rudimentary package that would be woefully inadequate for general use
but that is perfectly sufficient for my needs.

~~~
blueblob
I think that depends. ArchLinux packages are almost just bash scripts. People
can request fixes. I am sure when you first started programming you weren't an
expert and that same logic applies to making packages. Multiple distributions
you may be right.

I suppose it is fair enough that you would want to install third party
packages from source but with most package managers I would guess you could
download the package and look at how it is built or at least what files it
contains. Using packages can make cleaning up a bad package easier.

~~~
dfc
If there is not a proper Debian package you can use checkinstall or GNU stow.
This lets you install from a source tarball and be able to cleanly remove the
installation if something happens, good or bad. (proper debian package /
botched compile/install)

------
rdtsc
This cannot be overstated, I have heard during conferences packagers being
made fun of, something to the effect of "they are so cute, they don't
understand our problems".

To me it seem some are stuck between a rock and a hard place -- distro
requirements vs application specific (vendor) requirements.

So vendor likes to bundle specific library .so in the package or compiles
external modules as static. Distro requirement, for security reasons for
example, disallow that. Packager is left in the middle trying to reconcile the
differences between the two. I have seen people stop maintaining their
packages.

Yeah sometimes there is nothing you can do and the latest coolest database or
web browser or game just can't easily go into the main distro.

But also I can't tell you how happy I have been in the past if a library I
wanted to use was in the repo and I could just to an apt-get or yum install
and all that is due to someone putting the work into doing that. Now instead
of packaging it myself, building it, I saved a lot of time.

------
keenerd
Hey Arch-folk! Top requests for AUR packages you'd like to see brought into
the [community] repository?

edit: Or previously unavailable software that should be in the AUR?

~~~
bretthoerner
I just looked at my AUR list and most are non-free. A couple popular standouts
that are free: shutter, vagrant, gradle, leiningen, apache-ivy, jq

~~~
sentenza
I'd add bittorrent-sync. Encrypted, de-centralized Dropbox replacement.

~~~
bretthoerner
That isn't free (as in open source), so I left that out.

~~~
sentenza
Fair enough.

They claim to be thinking about open sourcing it, so there may be hope yet.

~~~
nodata
Meanwhile...
[https://github.com/calmh/syncthing](https://github.com/calmh/syncthing)

------
patcon
Or ask them to join Gittip! After they're signed up, others will be able to
start giving them recurring weekly gifts that are totally anonymous and
categorically no-strings-attached. It's like a DFTBA grant.

Disclaimer: I've taken 4 months off work to help work on the platform.

------
eplumlee
Don't just thank them. If you cannot support with your time, send them new
hardware and beer.

------
abruzzi
I thank my packager by paying them ~$12k a year for "support".

------
xfalcox
After being forced to use a non Debian distro at new servers at work (SLES) I
am so proud of Ubuntu packaging community.

~~~
TallGuyShort
Debian does have an impressive list of packages, but I'd rather use Zypper
than Apt any day. It's the only mainstream package manager that actually lets
you choose what to do when a dependency can't be satisfied or there's a
version mismatch.

------
jude-
I'm lazy when it comes to these things, so I use FPM. It's great if you're
dealing with RPM and .deb packages (and a few others). I saw someone else
(vacri) mention it in this thread, but it definitely deserves consideration if
you want to side-step setting up a packaging environment.

Link:
[https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm)

------
ksk
To me, its rather sad that we still have to rely on multiple third party apps
for dependency management - something that a modern OS should have baked into
its core branch.

------
caycep
could they have used a better example than MUMPS tho....yes, I know it works
with its peculiar brand of duct tape, chewing gum and baling wire, but
still...

