Re: /usr/man -> /usr/share/man, etc
> > > 2. The dependency is not real: the package's functionality does not
> > > depend on man-db. Suppose I'm building a firewall: I don't need the
> > > manpages, and I certainly don't need the man program(s).
> > No, it's not a problem. The proper way to implement this is to add a
> > `Conflicts' with older versions of man-db.
> Hmmm, yeah, a Conflicts would work. Except for point three. And the
> fact that installing one package from potato that used the Conflict
> would force an upgrade.
And that's the idea!
>
> > > 3. It won't work. The actual desired dependency is on the content of a
> > > configuration file, which won't be updated if the user has edited the
> > > manpath config file.
> >
> > Uh? Who cares? Dependencies have always worked this way.
> Huh? No, the vast majority of dependencies are on functionality, not
> configuration.
I doesn't make a difference. A package may depend on certain version of
sysvinit because it handles a certain thing in one of its configuration
files. A package might depend on a certain version of apache, the one that
have the Debian web standards compliant httpd.conf (these are imaginary
examples, it's late here.. =) ).
> I guess it just seems to me to be a lot of work to implement a huge
> hammer to pound down a very small nail. Just put it in the upgrade docs.
Now it is. If the upgrade had been better planned, we would have be able to
do this very easily, because we would have got a precise "FHS migration
guidelines for upgrading your pet package". Now this discussion is rather
pointless.. =)
Reply to: