Just want to lay out some ofthe technical issues we've kicked around on #fink. It seems like there are two workable solutions here if we are going to be removing -shlibs pkgs from the Depends field:
1. Add the new {SHLIB_DEPS} token to the Depends field.
2. Switch to Info3, and implement RuntimeDepends (with {SHLIB_DEPS}) or AutoShlibs:true.
There is something that I am still not getting: When the Info2 wrapper was introduced, the then "new" fink was still able to treat the old info files correctly as before. What is proposed now would break this backwards compatibility, and even the introduction of Info3 would not help, because you want to change the behavior of fink for info files that do *not* have this new feature.
This is inacceptable.
The other incompatibility you are worrying about, namely what "old" fink would do with "new" info files, is not really a problem: Introduce the new AutoShlibs field and require that people who want to drop *-shlibs dependencies from Depends use AutoShlibs:true. The "old" fink will just silently ignore the AutoShlibs field and it would then theoretically build debs with missing dependencies.
But:
Any selfupdate that brings info files with the new feature will also bring the new fink and install it first, so the combination "old fink" / "new info files" will never happen at the package bulding level. It will happen at the parsing level, but this would be harmless. This was different when variants were introduced, because the old fink could not parse the new info files and therefore without Info2 selfupdate would crash before it could get around to installing the new fink.
The underlying aim is to make sure that the Depends of these new-style
.info is not be processable by old fink, and that the result in this
situation gives users some useful clue about what is going on. By #1,
users of older fink who get a new .info might get a "cannot resolve
pkg {SHLIB_DEPS}", so we document that this means "install a newer
fink". By #2, users of older fink will get indexer warnings that their
fink is too old, or at least that there is something wrong with the
.info (which is how the whole InfoN system is designed).
If you keep backward compatibility, this is not necessary this time.
If we remove things from Depends and do not make that line
unprocessable, we cause problems for users who have existing
uninstalled .deb: 'fink install foo' looks in the .info not the .deb
for dependencies (I believe this will change in the new fink), so it
will not know to install the -shlibs dependencies and then "dpkg -i"
will crash with unresolved dependencies. That's a much less (IMO)
useful error message about what's really wrong ("old fink") and less
fink-like (one of fink's strong points is that it avoids dropping
users into dependency hell). Note that adding a BuildDepends on the
new fink will not work, because the pkg is already built.
I don't see the conflict you are describing here. You are talking about a deb file built with "old" fink from an "old" info file and you worry about what "new" fink install would do when the info file has been changed to "new" style, too. Well, I think chances are very slim that the package revision number would still be the same ;-)
-- Martin
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
