On Mon, 21 Nov 2005 10:47:18 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Nov 2005, Ricardo Mones wrote:
> > On Sun, 20 Nov 2005 12:13:48 +0100
> > Bill Allombert <[EMAIL PROTECTED]> 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
