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

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



Reply to: