Max Horn <[EMAIL PROTECTED]> wrote: > At 9:51 Uhr -0400 25.04.2002, David R. Morrison wrote: > >Max Horn <[EMAIL PROTECTED]> wrote: > > > >> At 7:22 Uhr -0400 25.04.2002, David R. Morrison wrote: > >> > >[snip] > >> > >> >So I would think that this package should be split into three pieces, > >> >maybe the third one to be called gdk-pixbuf-loaders. It would be treated > >> >like the binaries are treated in some other pakcages. Splitting > >>it off gives > >> >the possibility of allowing the dkpg/shlibs system to install multiple > >> >versioned copies of the dylibs, without getting conflicts between .so > >> >files. > >> > >> I am not sure that would actually work, see above: the loadable > >> modules might not work with different versions of the .dylibs. > >> > > > >The same is true of binaries. > > > >Here was my idea: > > > >SplitOff: << > > Package: %N-shlibs > >... > ><< > >SplitOff2: << > > Package: %N-loaders > > Depends: %N-shlibs (= %v-%r) > > Files: lib/gdk-pixbuf/loaders > ><< > > > >That's what we do with binaries. > > Only that this doesn't prevent "gdk-pixbuf22-loaders" to be installed > in parallel to "gdk-pixbuf23-loaders". They will collide, though, > because both contain the same files. So you also need a conflicts for > that. >
Sure. If there is an incompatible version later on, we have to add Conflicts. Just like for binaries. > > > Maybe the (= %v-%r) is too restrictive, > >but eventually that will be handled by the dpkg/shlibs system, to get > >the correct versions in place. > > > >Other packages would need to say "Depends: gdk-pixbuf-loaders" when > >appropriate. > > > >I guess we might call it gdk-pixbuf-plugins instead; that might be more > >clear. > > You realize that you will have to update several dozens of packages then? There is an upgrade strategy: put Depends: %N-loaders into the main package. This is a *temporary* dependency, so that this upgrade can be made without breaking anything. Later, other packages can be updated to have the correct dependencies, and then this dependency can be removed. Again, it is the same strategy as with binaries. -- Dave _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel