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