[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,

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 have thought about what
should go into it, and I thought of the following:

- 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.

- 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 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, you can setup 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.  Thoughts?

--   
Aaron Isotton

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



Reply to: