Re: I'm sorry to open another can of worms but.. /usr/share/man transition
My apologies; this was supposed to go to -policy, not -devel.
On Mon, Aug 09, 1999 at 02:00:05PM -0700, Nathaniel Smith wrote:
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: