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.
MfG
Goswin
Reply to: