Thanks to Andrew's work on PEP 241, I finally got motivated
to revisit bdist commands for Solaris pkgtool and HP's SD-UX.
Attached are three files bdist_packager.py provides an abstract
base class for bdist commands. It provides easy access to all
the PEP 241 metadata fields, plus "revision" for the package
revision and installation scripts for preinstall, postinstall
preremove, and postremove. That covers the base characteristics
of all the package managers that I'm familiar with. If anyone
can think of any others, let me know, otherwise additional
extensions would be implemented in the specific packager's
commands. I would, however, discourage _requiring_ any
additional fields. It would be nice if by simply supplying
the PEP241 metadata under the [bdist_packager] section
all subclassed packagers worked with no further effort.
It also has rudimentary relocation support by including
a --no-autorelocate option.
The bdist_packager is also where I see creating seperate
binary packages for sub-packages supported. My need for
that is much less than my desire for it right now, so I
didn't give it much thought as I wrote it. I'd be delighted
to hear any comments and suggestions on how to approach
sub-packaging, though.
The bdist_pktool command provides support for the Solaris
pkgadd and pkgrm commands. In most cases, no additional
options beyond the PEP 241 options are required. An
exception is if the package name is >9 characters, a
--pkg-abrev option is required because that's all pkgtool
will handle. It makes listing the packages on the system
a pain, but the actual package files produced do match
name-version-revision-pyvers.pkg format. By default,
bdist_pkgtool provides request, postinstall, preremove,
and postremove scripts that will properly relocate
modules to the site-packages directory and recompile
all .py modules on the target machine. An author
can provide a custom request script and either have
it auto-relocate by merging the scripts, or inhibit
auto-relocation with --no-autorelocate.
The bdist_sdux command provides the same functionality
as the pkgtool command, except the resulting packages
cannot auto-relocate. Instead, a checkinstall script
is included by default that determines of the target
machines python installation matches that of the
creating machine. If not, it bails out and provides
the installer with the correct version of the swinstall
command to place it in the proper directory.
I have tested both these with some local packages, and
with Marc-Andre's Egenix-mx-base. They work as long
as the result is a single directory tree under site-packages.
If anyone has modules that require multiple site-packages
directories, or install in multiple directories somewhere
else, I'd appreciate a note telling me where I can get them
for testing. (I can almost gaurantee they won't handle
header files properly.)
Finally, I have some questions regarding some things I
don't think I totally grasp.
First, is there a Distutils method for determining the modules
root directory under site-packages? I hacked it by grabbing
distribution.packages[0], but that's probably easily broken.
Second, in order to handle setup.cfg options in the subclassed
commands, I had to scan
self.distribution.get_option_dict('bdist_packager') and copy
options to the instance during initialize_options. Somehow,
that just feels wrong. Shouldn't they be inherited somehow?
There's still some stuff to do. I'd like to have seperate
classes for doc files, like rpm does, but I also want as
much of the setup configuration as possible to be in the
binary_packager class so it doesn't have to be replicated
by every possible packager command. Any ideas on a "generic"
way to specify file "classes", like headers, docs, etc.
please let me know (including pointers to discussions
already had....I know there where some, but I couldn't
readily find them). I think the concept is probably best
handled in the same way as producing multiple packages;
so if you specify doc files, a seperate "doc" package
would be produced. How does that sound?
Anyway, if you've got Solaris and HP access, please give
them a workout and let me know how it goes. (You MUST
have the PEP 241 patches, or you won't be able to get
to any of those options.)
Mark Alexander
mwa(a)gate.net