Hacker News new | ask | show | jobs
by etal 5739 days ago
Ruby, Perl and Python packages usually come with a README that says:

  This depends on these external packages: ...
Java programs usually come with a bunch of .jar files which were once independent packages, but have been dropped into the release itself. No dependency problems!

Then, if someone wants to package a Java application for Debian, the process is:

1. Look through the collection of .jar files in the release

2. Do you recognize one of these as already being packaged for Debian?

3. Work with upstream to delete that .jar from Debian's copy and depend on the system's version instead

4. Repeat for every other .jar in the release, until you hit a wall

5. Upload the package to Debian with an acceptably small number of bundled .jars

6. Time permitting, get someone to package the other .jars that aren't available in Debian yet

That said, you can cause a similar amount of trouble in other languages, it's just not the convention (thanks to the success of gems, CPAN, PyPI). For example, Ubuntu appears to have deleted the sagemath package because upstream keeps their own patched copies of dozens of libraries they depend on:

http://packages.ubuntu.com/search?keywords=sagemath&sear...

1 comments

They generally do much better than a README: machine-parseable is the way to go.

Perl (CPAN) packages include a YAML file that specifies what other modules (packages) and what minimum version of each is required to configure, build and run the package. There's an ecosystem of tools available for turning a Perl package into an RPM or deb, some of which can even work recursively. Even before the YAML was standard in CPAN packages, it just wasn't that hard to parse out all the "use" and "require" statements to automatically detect all the required packages (and minimum versions of those). There's also a unit testing framework to make sure you don't accidentally introduce any incompatibilities with untested newer versions of required packages.

I haven't dealt with Ruby quite as much, but the gem format also includes dependency information and there's gem2rpm for RPM and dpkg-gem for deb packages.

I think I've only ever once had to build an RPM or deb package of a Python package, but Python seems to natively support building both formats; just call the same "build and install" method you'd usually use with an extra argument and you get a native package, which will use dependency information if the python package provided it.