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
