Re: smarter way to differ architectures needed?
This argument is quite correct if we are talking about a full Debian
mirror and installations being made from such a mirror. However, I am
arguing from a different position, namely from a Hurd installation CD or a
Hurd only archive.
On 9 Apr 2001, Brian May wrote:
> >>>>> "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.
If someone wanted to do this, then they could install from a full mirror.
But my question still remains, should it be on a Hurd installation CD?
Should it be included in a Hurd sub-set archive? I maintain such a
sub-set and produce CDs from it.
> 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.
I basic problem as I see it is that there is nothing in the control file
that can differentiate between what would be _useful_ on a Hurd CD (or
in partial mirror) and what is not. At the moment I am excluding about
400 MB from the Hurd CDs because it is not useful, but it can still be
installed. In time Linux will feel the effect of the Hurd clutter on its
CDs and partial mirrors. Mind you, as a Hurd advocate I don't think that
this is a bad thing, but in time others may start to object ;)
> 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.
More unnecessary clutter? Sure, it can be installed, but why have it on
a Hurd CD or in a partial mirror?
> (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.
Here here!!!!!!!! But how? Who is going to do it? At the moment I am
probably the only person being frustrated by this, but I am the first of
many. We will probably be able to bumble our way through woody as I can't
see an official release of the Hurd before then, but after woody ...
Some action now could save much frustration in twelve months.
Phil.
-
Philip Charles; 39a Paterson St., Dunedin, New Zealand; +64 3 4882818
Mobile 025 267 9420. I sell GNU/Linux CDs. See http://www.copyleft.co.nz
philipc@copyleft.co.nz - preferred. philipc@debian.org
Reply to: