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? > > Secondly, the fink web site seems to be down so where do I submit packages? The sourceforge tracker isn't down, fortunately. Go to http://sourceforge.net/projects/fink/ and there's a Tracker item on the menu bar. > > Thanks, > Scott > > 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. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ 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
