Re: I'm sorry to open another can of worms but.. /usr/share/man transition
On Tue, Aug 03, 1999 at 11:44:08PM -0700, Joey Hess wrote:
> Well we arn't getting anywhere at all with a good transition to
> /usr/share/doc, but perhaps this will be easier.
>
> I'm concerned about what happens when packages start using /usr/share/man.
> Suppose I convert alien to put it's man pages there. Alien is arch
> independant and there is no reason someone using stable can't install the
> latest version from unstable. But when they do, they discover they can no
> longer read alien's man page, becuase their old man browser doesn't grok
> /usr/share/man. What to do?
>
> One idea that comes to mind is to make any package that uses /usr/share/man
> depend on some package. This might be "man-db (>= 2.3.10-69g)" which is the
> first version that support /usr/share/man. Or it might need to be some other
> package which itself conflicts with old versions of all the man browsers out
> there, to ensure only new ones are installed.
I'll just point out that most packages from potato won't work on slink anyway,
because of the libc change. In fact, while I don't have the control file for
the -69g version of man-db, I'm fairly certain that it depends on glibc 2.1,
given that it was released 2 months after glibc 2.1 went in. And, while
partial upgrades are nice and all, I've talked to way too many people on
#debian who got screwed when they tried to do a partial upgrade involving a
switch to libc 2.1. Currently, it seems that if you want libc 2.1, you pretty
much have to go to potato all the way (I haven't analysed why this is so, but
it seems to be both logical (there's _way_ too much that can break with
something as fundamental as libc changing), and supported empirically).
Additionally, most packages with man pages will themselves depend on libc
>= 2.1-1 because they contain compiled code. Alien happens to be perl (IIRC)
so this doesn't apply, but it's the exception more than the rule.
The upshot of all this is that if partial upgrades to glibc 2.1 aren't
supported (which seems to be the case), then the only thing currently broken
is packages that contain manpages but no compiled programs. These packages
are broken in the sense that you can install them on a slink system, but you
won't be able to read the manpages. The fix proposed is more or less to
disallow them to be installed on slink systems (unless you like massive libc
related breakage), which may be worse than the original problem (instead of
being merely undocumented, they become unusable).
> The problem with this idea of course is it means the majority of packages
> have a dependancy added to them. This doesn't seem like a large drawback in
> my eyes, especially because the average package depends on (checks) 2.57
> packages already and it dpkg seems to be handling that fine.
Umm... I'm dubious about a solution that increases the Depends: line of most
every package for all time, when said solution will have to be duplicated for
any change that effects many packages. Especially since we could end up with
a new item in the Depends: not just for man-db, but for everything that changes
unders FHS, and any other big change that may be in the future. And in this
case, this is to try to support a partial upgrade that won't really work
anyway.
If anyone would like to prove me wrong (or right, for that matter), especially
regarding upgrading to potato libc on slink, please go ahead.
-- Nathaniel
Reply to: