[Mailman-Developers] configure/build/packaging problems

[John Dennis]

I picked up responsibility for the mailman rpm here at Red Hat a little
while ago, just about the time of the 2.1 release. As a consequence I
don't have a history with the prior releases, but I seem to have run
into some build and packaging problems that I think were introduced in
2.1 and then carried over into 2.1.1.

I believe as of 2.1 it became a requirement that the mailman user and
group exist before the configure script is run. As far as I can tell
this is because the configure script looks up user ids and/or user
names in the system passwd database when its building its set of
substitution strings for the .in files.

One of the problems I've encountered is that production of the mailman
RPM is done on machines where the set of users and groups are fixed
for a variety of package production robustness reasons and I've lost
the battle and have been told mailman must build without requiring the
existence of a specific user. Whether one has sympathy for the rule or
not is of little value, it is what it is. By the way, this problem
just came to light as Red Hat users upgraded to Red Hat 9 which
includes the mailman 2.1 release. In the interim I have produced a
2.1.1 rpm, but that is only available as a separate download. The
problem was that some build machines had the user/group 'mailman'
predefined and others did not, so some rpm's were good but others
ended up with bogus configurations.

I've studied the configure script in some detail and I think I
understand the areas that need fixing but before I do that I'd like to
ask some questions to sanity check my thinking before I go down the
wrong rat hole.

1) At the heart of the mailman build philosophy seems to be the notion
that mailman will (must?) be built on the target system. This seems to
be in opposition to packaging concepts where a software component is
built on an unrelated build machine, the resulting files gathered into
an installation package, and then that package is installed on the
target. Given that packaging is a common distribution mechanism I
assume the approach of requiring the package to build on the target
was a deliberate choice for some reason. If so what was the reason?
If there isn't a compelling reason for the approach are you open to
receiving patches that make the configure/build step friendly to
packaging requirements or does this violate some principle mailman is
trying to maintain?

2) I've noticed that some of the checks and lookups done in configure
can be controlled with with-permcheck & without-permcheck. But not all
the lookups are under the control of this variable. My initial
thoughts were to have ALL the local lookups under the control of this
variable, if without-permcheck is set then NO local lookups during
configure/build are performed, configuration values are used as
supplied. Does this sound reasonable? Is this overloading this
variable with meaning that was not intended?

3) I've also run into problems where the .py files cannot be compiled
into .pyc files on build system during the build. The culprit is the
paths.py file which is included by quite a few of the python
files. The problem is that paths.py has a hardcoded pathname
(generated by the configure step) that only exists in the
post-installed target. It does not exist on the build
machine. Therefore some of the compiles fail because some of the
source python files include files via paths.py that don't exist
(yet). This means the compilation needs to be postponed to
post-installation on the target. My understanding is that the python
interpreter will drop a .pyc file in the source directory the first
time it compiles the .py file so in theory its like a lazy
compilation. But this has a few problems too, the python process has
to have permission to write in that directory and it violates some
packaging requirements that every file belonging to a package exists and
is known at both package install and package remove time. I haven't
really looked into what is required to fix this problem yet but it
seems like we have to get rid of the hardcoded pathnames in paths.py
and if someone has a suggestion I'd be curious to hear. I'd really
like to be able to compile the python files during build before
producing the installation package.

John