On Thu, 1 Mar 2012 13:57:31 -0800, David Lowe <doctorjl...@verizon.net> wrote:

> On 19 Feb, 2012, at 10:20 AM, Alexander Hansen wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > > On 2/19/12 12:52 PM, David Lowe wrote:
> >> So i finally get around to enabling the SDL version of the freeciv
> >> package.  After overcoming a few small hurdles i now face this:
> >> >>> Unpacking freeciv-sdl (from
> >>> .../freeciv-sdl_2.3.1-13_darwin-i386.deb) ... /sw/bin/dpkg: error
> >>> processing
> >>> 
> /sw/fink/dists/local/main/binary-darwin-i386/freeciv-sdl_2.3.1-13_darwin-i386.deb
> >>> (--install): trying to overwrite `/sw/bin/freeciv-manual', which
> >>> is also in package freeciv
> >> >> I know of no innate reason why the binaries can't co-exist, but my
> >> browsing through info files didn't turn up anything that obviously
> >> looked like a solution.  What are my options other than having the
> >> two variants 'Conflicts:' each other?
>
> > A few thoughts:
> > > 1)  Let freeciv and freeciv-sdl Conflicts: and Replaces: each other. 
> > That's easy, but if there's only the one file that overlaps another
> > solution might be preferable. 
> > > 2)  Rename freeciv-manual in _both_ variants to avoid overlap, and use
> > update-alternatives to allow fink (or the user) to select which one of
> > the renamed items will provide 'freeciv-manual'.  That avoids the
> > Conflicts/Replaces between variants, at the expense of a little
> > additional work in a PostInstScript and PreRmScript. 
> > > 3)  A separate freeciv-manual package (I'm assuming that it's a manual
> > :-) ) which both freeciv and freeciv-sdl would Depend (or
> > RuntimeDepend) on.  This would entail an additional package
> > description.  Unfortunately you can't just do it as a Splitoff,
> > because it's forbidden to have an invariantly-named Splitoff of a
> > varianted package. 
> > > 4)  A freeciv-manual package and a freeciv-manual-sdl package which
> > are Splitoffs of freeciv and freeciv-sdl respectively.  They'd both
> > contain the freeciv-manual executable, Conflict/Replace each other,
> > but you'd set the dependencies in freeciv and freeciv-sdl to allow for
> > both, e.g. 
> > > RuntimeDepends: ... freeciv-manual (=%n-%v) | freeciv-manual-sdl (=%n-%v)
> > > I'm thinking RuntimeDepends might come in handy here to avoid
> > deadlocks at build time. 
>
>  After some research, i plan to implement something similar to the 
> way this is done in Debian.  The package will have more variants:
>
> 1) freeciv [just the gtk2 client]
> 2) freeciv-sdl [just the client]
> 3) freeciv-server [backend which is not needed for multiplayer games]
> 4) freeciv-common [graphics & sounds for all clients, the manual, and 
> some small utilities]
>
>  So this is basically another tack on Mr. Hansen's option 3.  My new 
> problem is that there is no configure option to disable creation of 
> the manual.  Now i *imagine* the fix would be a PreInstScript that 
> goes into the build directory and deletes the manual subdirectory, 
> but i'm open to any other ideas.  If this is to be the way, can 
> anybody suggest what info file would be a good example for how to do 
> this?

PreInst is a "dpkg installing the .deb into the live filesystem" not 
"during creation of the .deb archive for later use". I'm pretty sure 
filename collisions are handled in dpkg based on its own records of 
what it installed, not the current state of the filesystem. And PreInst 
doesn't happen until dpkg has decided that it can actually likely 
install it, which would be well after it aborted due to the collision, 
if I understand your plan. You need to delete the files from the 
install staging directory (%i) during InstallScript, so that the actual 
package (.deb) that dpkg is handling is not colliding. The alternative 
is to hack the makefiles so that the manual isn't generated. I'm not 
sure the amount of time and dependencies needed for generating them, so 
I don't know if there's a substantial advantage (to users) of disabling 
their generation rather than generating-then-wasting. 

dan

  --
Daniel Macks
dma...@netspace.org



------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to