On Tue, Apr 27, 2010 at 12:50:43PM -0400, Jack Howarth wrote: > On Tue, Apr 27, 2010 at 06:20:41PM +0200, Jean-Fran?ois Mertens wrote: > > > > On 27 Apr 2010, at 18:07, Jack Howarth wrote: > > > >> On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-Fran?ois Mertens wrote: > >>> > >>> On 27 Apr 2010, at 17:43, Jack Howarth wrote: > >>> > >>>> To recap, the problem with using a single package with split-off > >>>> strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ > >>>> Replaces on the older gcc4x packages which have overlapping files. > >>>> This is because the older gcc4x packages can't know that they are > >>>> are able co-exist with the newer gcc4x package and will Conflict > >>>> with > >>>> it. > >>>> This causes dependency failures for fink in the absence of an > >>>> explicit > >>> > >>> Jack _ I told you since the beginning (Re: co-existing gcc4x > >>> packages, > >>> april 25) that it would be much simpler to keep the name gcc45 for > >>> the > >>> splitoff containing the symlinks _ This way, no need to bother other > >>> pkgs, and you > >>> avoid the trouble you mention.. > >>> > >>> Jean-Francois > >> > >> JF, > >> Isn't that going to be considered a massive violation of fink > >> policy for shared library packages? > > I don't see why.. > >> It's sort of like using > >> update-alternatives for manpages and info files. > > http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg19967.html > > > ??? > >> It can be done > >> but many here will find it more repulsive than having package > >> maintainers update the BuildDepends. > > Again, I don't see why .. > > http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#sharedlibs > > The approach you describe has never been implemented before and I > wouldn't want to be the first unless the core maintainers were okay with it.
It's approximately how perl is set up. We have perlXXX as the mutually-exclusive (generic filenames in default locations) package, with perlXXX-core as the concurrently-installable (files or directories named specifically for the "XXX") back-end. Other packages that are specific to a certain perl version have a dependency on the perlXXX-core they want and access it as (for example) bin/perlX.X.X. A package that would really need "bin/perl, as a certain perl version" would have a dependency on perlXXX itself. (other concerns snipped, some addressed others in agreement per my other email a few minute ago--things are laggy here:(. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
