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

Re: Spliting packages between pkg and pkg-data

On Mon, 21 Nov 2005, Ricardo Mones wrote:
> On Sun, 20 Nov 2005 12:13:48 +0100
> Bill Allombert <allomber@math.u-bordeaux.fr> wrote:
> > When doing research about circular-deps, I looked at a lot of packages
> > that are split between a binary package and a data package. This is a
> > good thing since this reduce the total siez of the archive, however
> > there are simple rules that should be followed:
> > 
> > 1) Make sure pkg-data is actually arch: all.
> > 
> > 2) Name it in a way that make the relationship obvious: For example,
> >    if the upstream name is 'foo', name the binary package 'foo' and the
> >    data package 'foo-data'.  
> > 
> > 3) Keep the files that 'signal' executables in the same package than the
> >    executable (e.g. menu file, program manpage).
> > 
> > 4) Do not put symlinks in data packages that point to files in the binary
> >    package. This do not really save space and avoid dandling symlinks
> >    when the binary package is not installed.
> > 
> > 5) Of course move /usr/share/pkg to pkg-data.
> > 
> > 6) Do not make pkg-data to Depends on pkg.
> > 
> > 7) Try to do it correctly the first time: if you move file between
> >    pkg and pkg-data, you will need to use Replaces:
> > 
> > Please check your packages follow these rules, and if not, do not forget
> > about rule 7.
>   I'd suggest to add this to the best practices for debian/control in
> developers' reference. What do you think?

That it is incomplete.

1. -data packages should probably recommend their parent packages if they
   are useless without the main package.  And versioning should be used if
   possible (and needed, don't do it just because), but it cannot be too
   strict (= ${Source-Version}) between arch all and arch !all packages,
   since that breaks bin-NMUs (which is arguably a minor bug in the whole
   bin-NMU concept, or in dpkg's lack of a mostly equal operator that also
   matches bin-NMUs).

2. symlinks are just fine if there is a "depends" to ensure they are not
   dangling (and we are not talking about essential binaries, etc).  For
   optional -data packages, which the main package does _not_ depend on (and
   instead suggests or recommends the -data package), it is feasible for
   the -data package to depend on the main one and have symlinks to the main
   one, and it is not a bad thing at all to use them.

3. Loose dependencies between -data and main packages *CAN* create breakage
   on partial upgrades, depending on just how tight the relationship between
   a particular version of the package and its arch-indep data is.  Watch
   out for this, it is NOT always an easy problem to solve because of bin

4. Also IMHO one should at the very least suggest the main package from the
   -data package.  This helps the users of non-crappy apt frontends to
   track the main package starting from the -data package.  Relying on
   package naming alone for this is suboptimal at best.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: