Re: smarter way to differ architectures needed?
>>>>> "Philip" == Philip Charles <philipc@copyleft.co.nz> writes:
Philip> I can see a grey area, could <--> should.
Philip> Example. kernel.doc _could_ be installed on a Hurd system
Philip> as there is no technical reason preventing this. However,
Philip> I decided that it _should_ not be installed as imo it has
Philip> nothing to do with the Hurd.
I think kernel.doc is a bad example, because you could use it on any
platform, as I assume it contains ASCII (whether HTML, info page, man
page, XML, or whatever) data that can be read on any platform. So,
just because I have a Hurd system, I might still want to install
kernel.doc, so I can read about how to do something on my Linux
box. Or, perhaps I have a vague feeling that X is possible of Linux,
but want to know if it is possible on the Hurd, but can't remember
what X is even called.
Also keep in mind the difference between depend, recommends, and
suggests. So you might want kernel.doc to "recommend: os-linux"
(note: it is ages since I read policy on suggest vs recommend, not
sure if recommend or suggest should be used here), but I would file a
bug report if it ever was "depend: os-linux" unless this really could
be justified.
Philip> So kernel.doc needs to be identified so that, 1. It is
Philip> not included in the Hurd Packages file. 2. If someone
Philip> wanted to install it on a Hurd system dpkg/apt would not
Philip> object.
I disagree. I think kernel.doc should go in the Packages file for the
Hurd, unless you can justify that it won't work on that platform.
(I have to admit it is a grey area though: just what do you mean by
"won't work"? I could install kernel.doc, and try some of the examples
on my Hurd system, and it probably "won't work").
Sure, it does increase the size of the Packages file for Hurd people
by adding yet another package most people want won't, but I would
argue that is a limitation in the Packages index file that must be
independently addressed.
--
Brian May <bam@debian.org>
Reply to: