On Oct 21, 2012, at 3:27 PM, Alexander Hansen <alexanderk.han...@gmail.com> wrote:
> On 10/21/12 10:40 AM, Scott Hannahs wrote: >> I have a package (duplicity) that for some reason did not get moved to the >> 10.8 tree. > > The reason would be that you didn't ask to have it done. :-) We haven't > been moving things automatically, and so packages that nothing else > depend on can get left behind. > > I have updated the package and it builds on Mac OS X 10.8, 10.6 and 10.5. >> >> The package is dependent on python. The minimum requirement is python 2.4 >> and has been tested up to python 2.7. What is the best route >> A. Require python 2.7 in the dependencies since it is available in all >> systems as a build >> B. Let the user chose by creating a duplicity-py24, duplicity-py25, >> duplicity-py26 and duplicity-py27 >> C. Other, is there a method for creating a dependence on "python (>= >> 2.4)" ?? >> >> I have created the updated version based on A but that forces a large >> install for many users. Option B seems more user interaction than is >> necessary for such a package. C would be fine but I haven't seen that used >> in any other package and not sure it is legal. Also there is a dependence >> on boto-py27 which is explicit. My current depends are: >> # Dependencies. >> BuildDepends: librsync (>= 0.9.7-1002), fink (>= 0.24.12-1) >> Depends: python27, librsync-shlibs (>= 0.9.7-1002), ncftp, lftp, boto-py27 >> >> There are cases where a user would want python 2.6 or greater since it >> allows multiprocessing some of the data transfers but is there a better way >> to make the package use already installed or system versions of python? > > This is an package focusing on a user executable, yes? > > Some maintainers like to do variants for multiple Python versions in > such cases and then use update-alternatives to select the executable > (your B). Pros: users don't have to install an additional python. > Cons: harder to maintain > > For maintenance purposes, it's usually easier just to pick a single > Python version (A). Pros: simple to maintain. Cons: users gripe about > having to install python27 if they have some other version installed. > > A dependence on "python" isn't that useful, since that's a convenience > package pointing by default to python27. > > Something like option (C) isn't allowable unless a package just runs > Python scripts. If there is any linkage to a libpython then one can't > swap in a different version. > > Use of the system's Python would require the entire dependency chain of > Python modules also to be built against the system's Python. If a > package doesn't use any other Python modules, but instead just needs a > Python to run scripts, that's different. I think it is just a collection of python scripts. There may be one compiled module to deal with rsync though. I didn't know about update-alternatives but it looks like something I may easily screw up. I'll submit option A that I have working. Thanks, Scott Dr. Scott Hannahs, Director of Scientific Instrumentation and Operations Distinguished University Scholar National High Magnetic Field Laboratory, Florida State University http://sthmac.magnet.fsu.edu 1800 E. Paul Dirac Dr., Tallahassee FL 32310, (850)644-0216/FAX 644-0534 "OS X: because making Unix user-friendly was easier than debugging Windows." ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ 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
