[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

What should go into "How Software Producers can distribute their products directly in .deb format"?



Hi,

(sorry for the overlong subject).

I originally sent this to debian-doc but I got no answers, so I
thought I'd post it here too.

I'm interested in writing the "How Software Producers can distribute
their products directly in .deb format" manual, as listed on
http://www.debian.org/doc/devel-manuals.  I thought to write the
following, more or less:

- First, consider the license of your product.  If it's
  DFSG-Compatible and of general interest, consider adding it to
  debian/main.  That'd be the best solution because of all the things
  like the BTS and the worldwide mirrors.  Or, if you don't want to do
  it yourself, ask for a packager on the mailing lists.

- If it's not DFSG-Compatible, but of general interest and you'd want
  it into debian, consider adding it to debian/non-free.  Or even
  better changing the license.

- Otherwise, read the New Maintainer's Guide / Debian Policy and all
  the other relevant docs.  Make a package using the normal debian
  tools, check it with lintian, try it, whatever.  There are a few
  "special" issues, though.  Unstable and testing are changing all the
  time; a closed-source package which isn't updated too often would
  probably quite soon get uninstallable because of some unsatisfied
  dependencies or break somehow.  Thus, build your package for stable,
  but do not use strictly versioned dependencies (i.e., require an
  exact version), but only >= dependencies.  So there's chance that
  it'll be installable/run also on testing and unstable.

- Consider putting fast-changing libraries/programs into your package
  instead of depending on the ones shipped with debian.  They could be
  installed into /usr/lib/<package-name>/.

- If you've got only few and/or seldom updated programs, shipping the
  .debs will probably do.  If you've got many and/or often updated
  programs, or just want to be cool, consider setting up your own
  package repository.

This is the basic idea for packages which can be adapted to the FHS in
a reasonable way; but for some really large, closed-source and older
programs that might be too difficult; it would probably be much easier
to put them into their "own" directory, with their own bin, lib, and
whatever other folders they need.  I know that isn't the "proper" way
to do it, but I'd prefer some program to be installed in this impure
way than overwriting some other files or sprinkling the file system
with mysterious configuration and cache files.  Or maybe it'd be
better to create directories such as /usr/bin/<package-name>/,
/usr/lib/<package-name> and so on.  I'm not too sure about this,
though.  Any ideas?

Anything wrong with this?  Improvements?  Comments?  Criticism?
Thanks.

-- 
Aaron Isotton

http://www.isotton.com/
My GPG Public Key: http://www.isotton.com/gpg-public-key



Reply to: