I didn't realize it, but fink supports a dependency of the form  
( =<version> ) without specifying a revision.

If all octave-using packages agree to use Depends: octave ( =<current  
version> ) | octave-atlas ( =<current version> ) [or an equivalent]  
rather than ( >=<current version>-1), then that will satisfy the prior  
breakage issue in a simpler packaging setup.

There has been some concern expressed about handling updates, and I  
think using such a versioned dependency will satisfy that.  We can go  
back to just having "octave" and so people will be able to update  
octave straightforwardly,  provided that all of the  packages that  
they have installed that depend on octave are updated to use the new  
version.   A transient inability to run "fink update-all" isn't that  
big of a cost in this case

That's a lot better than having to specify a versioning of ( =  
<current version>-<current revision> ) since that would require a  
package update even in the event of a trivial change in the octave  
packaging.

I'll do some testing to make sure it works properly.  Since I haven't  
done anything fancy with Provides or splitoffs in octave3.0.2, it  
should be a straightforward transition to move back.

The one drawback is that updating octave will break people's non-Fink  
stuff that is built against it,  but it's been doing that all along  
anyway.

Unless there's some solid reason that a versioned but not revisioned  
dependency will fail...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel

Reply via email to