On Thu, Feb 04, 1999 at 04:44:21PM -0500, Greg Ward wrote:
valuable! (So I can't understand why you-as-developer advocate pushing work onto the packager. >grin<)
Well, it if the things I wrote up for the packager would be the packagers only job, then I would have saved a lot of work compared to the current situation. ;-)) And on the other hand I know how someone feels if he has to determine how to compile a extension on a system he has no access too. ;-)
[...Greg gets a sinking feeling...]
Hopefully, this is not so bad, that you can't continue your good work? But sometimes you have to face reality as it is. ;-))))
This raises the danger of "yet another Makefile-that's-not-a-Makefile to edit" though. Yuck. Maybe we could call it "Setup" so existing Python hackers think they know what it is. ;-)
That is a little bit what I have seen to come up. ;-)))
we definitely need some expertise with Solaris 'pkg', the various Mac and Windows solutions, etc.
This would be helpful. For all packaging systems I know of, this is the way packages are build.
Oh: implementing a "bdist" command to create "dumb" built distributions (eg. a tar.gz or zip file) should still be pretty easy, though -- just tar/zip up the blib directory (minus documentation: hard to say where that should be installed, since there's no standard for module documentation). So *that* doesn't have to be punted on.
I would also leave inside the distutils package, cause this is something that we can easily deal with.
Sounds about right to me -- we haven't really discussed what meta-data is necessary, but this is a bare minimum. It should be at least a superset of what RPM knows, though.
I would suggest to have at least this information in the meta data - Name of the developer - Name of the package - package version - a one sentence - one line summary - a description field - a copyright notice, that means something like a short identifier for the used licence.
This is fine to hear. Is it also planned that I can check for a certain version of library or so? Let's say I need libtk.so.8.1.0 and not libtk.so.8.0.0 or is this kept anywhere else? How do you like to implement this tests?
No, that's not in the plan and it's a known weakness. Checking dependencies on Python itself and other Python modules should be doable, so that's what I think should be done. Open the door beyond that and you fall into a very deep rat-hole indeed -- a rat-hole that RPM takes care of quite nicely, and you argued very cogently that we should *not* duplicate what RPM (and others) already do!
Hm.. this is something I would have expected that distutils include. I have seen distutils a little bit like autoconf or so for Python in Python. Not as powerful, but with some basic features of autoconf. Cause this is information the developer can easily provide. But if this is possible to implement is the other question. I hope I haven't been to pessimistic or so. Bye, Oliver -- Oliver Andrich, RZ-Online, Schlossstrasse Str. 42, D-56068 Koblenz Telefon: 0261-3921027 / Fax: 0261-3921033 / Web: http://rhein-zeitung.de Private Homepage: http://andrich.net/