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
