[Distutils] bdist_nsis, bdist_deb, bdist_msi, bdist_inno, bdist_pkgtool, bdist_sdux, bdist_mpkg, etc.

[M.-A. Lemburg]

Ronald Oussoren wrote:
> 
> On 20-dec-2005, at 15:40, M.-A. Lemburg wrote:
>>
>> I'm sure Apple will add support for uninstall soon. Even if not,
>> we can easily add an uninstall script to the created package which
>> then removes all traces of the installed package - much like
>> bdist_wininst does in order to support uninstall of the Windows
>> package.
> 
> You're much more optimistic than me w.r.t. Apple provided uninstallers.
> Apple's installer does offer no protection whatsoever against replacing
> files that belong to another package, I suppose at least partially
> because Apple itself uses installer packages to ship patches. This makes
> uninstalling a lot harder.

There's a tool called "Uninstaller" which seems to go a long
way to fill the gap:

	http://macmagna.free.fr/?l=en&s=uninstaller

> It should not be too hard to write a limited uninstaller for OSX,
> information about installed packages is stored in /Library/Receipts and
> that includes information about all installed files.

Indeed.

>> Dependency management is a nice to have feature, but I
>> wouldn't consider it essential.
> 
> I've lived without dependency management for ages, but am disliking it
> because I end up playing the dependency engine myself. It would be very
> nice if the standard distutils package could at least provide a way to
> store dependency information in setup.py, a PKG-INFO file and/or on
> PyPI. That way users at least wouldn't have to search for dependencies
> in package documentation.

SVN distutils already supports PEP 314 style
provides/requires/obsoletes. It also uses this information
for building RPMs and for registering with PyPI.

Looking at PyPI, these are not yet in wide-spread use, though.

>> Automatic downloads are nice to have as well, but sys admins
>> rarely trust tools that automatically download and install
>> software, unless they have complete control of where things
>> are downloaded, when and whether there's proper authenticity
>> control built into the tool.
> 
> I'm not too happy about the downloading feature of setuptools because of
> the lack of verification. I haven't spent enough time with setuptools
> yet to decide how to reach a save-enough situation. There will always be
> some trust involved, even if packagse included digital signatures I'd
> have to trust the signer enough to assume that he won't insert malware
> into his package.

I think an author provided MD5 sum will already go
a long way for making sure that the registered upload
has not been tampered with. The signature will
additionally confirm authorship, provided you trust
the signer.

The PyPI upload command can automatically sign packages
that you upload. However, the same problem as for PEP 314
applies to this I guess.

>> AFAIK, easy_install doesn't
>> provide any kind of authenticity control - probably due to
>> the fact that PyPI doesn't have this feature. At least the
>> MD5 sum should be checked, but for this, the PyPI registry
>> would have to provide this information in some way.
> 
> Checking checksums is very nice of cource, but doesn't help against
> someone that registers hostile code with PyPI. Luckily PyPI protects
> against users that try to register new versions of projects they don't own.

True. MD5 sums are the minimum requirement, I suppose.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 20 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::