RE: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2
From: Ronald Oussoren
On 15-mei-04, at 0:23, Lars Immisch wrote:
From Bob:
Not all operating systems have a usable package management system (Win32, Mac OS X, probably others).
What's wrong with Installer.app and/or PackageMaker?
Both are installers, not package management systems. There is no public interface for listing which packages are installed and uninstalling packages, let alone dependency management.
Hmm. I'm not sure I see what you're saying here. If you're saying that a "usable package management system" needs to support a "public interface" for listing which packages are installed, uninstalling packages, and dependency management (which you'd need to define more clearly) then Windows certainly does have one (albeit a bit primitive). Applications which wish to participate in the standard "Add/Remove Programs" interface have to register certain registry keys, so to some extent that would count as a "public interface". Listing & uninstall only, there's no dependency management, but it's a start. And it's what the current bdist_wininst uses, so it's supported by distutils right now. What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do... Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________
On 17-mei-04, at 12:18, Moore, Paul wrote:
From: Ronald Oussoren
On 15-mei-04, at 0:23, Lars Immisch wrote:
From Bob:
Not all operating systems have a usable package management system (Win32, Mac OS X, probably others).
What's wrong with Installer.app and/or PackageMaker?
Both are installers, not package management systems. There is no public interface for listing which packages are installed and uninstalling packages, let alone dependency management.
Hmm. I'm not sure I see what you're saying here. If you're saying that a "usable package management system" needs to support a "public interface" for listing which packages are installed, uninstalling packages, and dependency management (which you'd need to define more clearly) then Windows certainly does have one (albeit a bit primitive).
Installer.app is for MacOS X. The big problem with Installer.app is that it can *only* be used to install application, Apple doesn't include an application to uninstall software.
Applications which wish to participate in the standard "Add/Remove Programs" interface have to register certain registry keys, so to some extent that would count as a "public interface". Listing & uninstall only, there's no dependency management, but it's a start. And it's what the current bdist_wininst uses, so it's supported by distutils right now.
What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do...
I'll let others answer this question, I've never used the bdist_* commands (other than bdist_dumb). Ronald
On Mon, May 17, 2004 at 11:18:46AM +0100, Moore, Paul wrote:
What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do...
In my view of the perfect world, the OS tools would deal with dependencies based on the metadata provided by the binary packages. This is how apt-get works. It wraps around dpkg and/or rpm. The .deb and .rpm packages provide the metadata and apt goes and gets whatever is necessary. It does not prevent people from pulling down individual .deb or .rpm files and working their way through (or even overriding) dependencies, if that's what they want to do. Nor is it required that you have an automatic dependency resolver ala apt. Since Windows does not provide that ability natively, then Distutils need not try to extend Windows to include it. Although an independent "apt-for-Windows" type too would, I'm sure, be appreciated by Windows users, it is not necessary for Windows package management any more than apt is required for .deb or .rpm management. RPM managed quite well for some time before apt-like tools became available -- It's only advantage over Windows "Add/Remove Programs" was dependency checking (not dependency resolution). This is why I believe the core value of Distutils is the simple management of package metadata. Building, installing or making binary packages are all actions based on the supplied metadata. How the result is integrated into any particular platform should be as native as possible for each platform. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/
participants (3)
-
Mark W. Alexander
-
Moore, Paul
-
Ronald Oussoren