On Mon, Feb 07, 2005 at 08:57:26AM +0100, Martin Costabel wrote: > Daniel Macks wrote: > >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.
I'm sorry if I didn't state my position here, but for the record I am against changing the meaning of the Depends field in existing files. I haven't proposed a way to make that change cleanly because I can't think of a way to do so. That said, the question is how to format these new files so they get the added functionality: where to put {BUILD_SHLIBS} or how else to get its effect, and perhaps how to specify (other) runtime-only dependencies. > This is inacceptable. I concur. I never said "...and change Depends to mean runtime-only". If we stuff {SHLIBS_DEPS} into Depends, then the build-time parser would ignore it. > 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. We do see people who get somehow "stuck" at a fink older than the most recent in their .info collection. The question is whether this is a common enough situation that we should try to solve the problems it would cause. Or at least if there are multiple ways to do [whatever else we're trying to do], we should consider it at all. > >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 ;-) That raises an interesting question: are we going to bump %r on each package we change to this new SHLIB_DEPS form? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- 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