Re: A thought on dependency checking
>When a dependency is checked it is checked against a package, correct?
>Sometimes packages get restructured, no?
Yes, most recently netstd and X.
>Why not have the dependency calculated from the package.list using the
>actual file required?
Cuz then you can't have tools like apt to resolve dependancy conflicts, you
can't have virtual provides, and it limits your flexibility to move things
around. Just think if something had depended on /usr/X11R6/lib/libXpm.so.4
instead of the xpm4.7 package! We wouldn't have been able to move it to
/usr/lib/libc5-compat. It would have interfered with the glibc-compiled
You also wind up with users wondering what package libm.so.6 is in now,
This is one of the problems Redhat has to deal with, because people are
actively using file dependancies instead of package dependancies.
>This would eliminate any dependency problems that
>develope from reorganizing packages.
No, what we need is another field in the package control file so that the
package upgrade tools (dselect, apt) recognize when one package renames
itself into one package (actually, we can do this now with Conflicts/
Replaces/Provides) or into several packages. (We currently can't do this.)
We need a name for it. It doesn't even have to be a good name, since most
users won't see it.
Or maybe we can hack it so that when two or more packages Replaces:
something, they are both automatically selected. (If this is current
behaviour, someone please speak up now - it would mean there are some
release-critical bugs to be filed.)
Robert Woodcock - email@example.com
"Unix and C are the ultimate computer viruses" -- Richard Gabriel