[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 10:47:18 -0200
Henrique de Moraes Holschuh <hmh@debian.org> wrote:

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

  I'm glad you decided to complete it :)  
> 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.

  That one rewrites the point 6 above as the opposite, which should
read: there is no problem in pkg-data depending on pkg as long as
you don't make pkg also depend on pkg-data, which triggers the circular
dependency problem. 

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

  Isn't it the same case when packaging external modules (shared
libraries) for a host application? The difference is shared libs are
arch-dependent, of course.
> 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.

  IMHO pkg-data package should also include an «Enhances: pkg» in
addition to the suggest. Both fields with some partial string matching
on the package names could make some frontend realize the kind
of relation between the packages.

  Ricardo Mones 
  You have the capacity to learn from mistakes. You'll learn a lot 
  today.                                           /usr/games/fortune

Reply to: