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

Re: Spliting packages between pkg and pkg-data

Daniel Burrows <dburrows@debian.org> writes:

> On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> was heard to say:
>> Nicolas Boullis <nboullis@debian.org> writes:
>> > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote:
>> >> Hello Debian developers,
>> >> 
>> >> 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:
>> >> 
>> >> 3) Keep the files that 'signal' executables in the same package than the
>> >>    executable (e.g. menu file, program manpage).
>> >
>> > Why? I agree that it menu files and manpages are generally not that 
>> > large, but what would it break to have them in pkg-data?
>> > (I would consider it strange to have such files out of the main pkg 
>> > package, but it looks policy-compliant as far as I can see...)
>> >
>> >
>> > Nicolas
>> foo depends on foo-data. But foo-data does NOT depend on foo.
>> So an "apt-get install foo-data", while being useless, is consistent
>> for dpkg. After that you would end up with a menu entry for foo but no
>> foo binary.
>   Shouldn't menu refuse to create menu entries for "foo" if the foo package
> is not installed?  At least, I thought that's what
> ?package(foo): ...
>   meant.
>   Daniel

Aparently yes. Menu seems to be smart enough for that, see other
mails. Bad example, sorry. But manpages certainly aren't.


Reply to: