Planning for 2.3/2.4
Hi Arno,
On Friday 06 January 2012, Arno Töll wrote:
> I think I will start working on 2.3 this weekend, do you have any
> particular suggestions how we should coordinate our work?
Why, I thought I'd just sit back and make smart comments and you (and
maybe some other new people) do all the work ;-)
Just kidding... But I think I will work on upstream 2.4 and an apache2
DSA before I will do anything for the Debian 2.3/2.4 package. So there
shouldn't be much need to coordinate for at least 2 weeks.
> If not,
> I'd just make a remote branch everyone would need to rebase before
> pushing changes.
That's ok with me.
I have lots ideas about the 2.4 packages, though. These are of course
not set in stone but a base for discussion.
The separate mpm packages should go away. All mpm modules should go
into the -bin package.
We also want only one -dev package. I am not sure yet what this means
for php, but we (or the php maintainers) will have to sort that out.
Probably mod_php should still be compiled without thread support and
abort with an error message if used with a threaded mpm.
I would just remove mpm-itk for now. There is mod_privileges in 2.4
which uses Solaris privileges to achieve something like mpm-itk. Maybe
mpm-itk for 2.4 can use a similar approach and exist as a normal
module instead of as an mpm. But that's something itk upstream has to
worry about.
The fact that apache2.2-common contains the apache2 config files
creates some problems. Suppose it is replaced with apache2.4-common,
which would conflict with apache2.2-common and also contain the config
files. This means that the config files have to move from one package
to the other during update. During the upgrade from 2.0 to 2.2 this
has caused problems because apt-get --purge dist-upgrade then apt-get
purges the old package first (including any user-modified config) and
only then installs the new package. We will have to work around that
during the 2.2 to 2.4 upgrade, too, but maybe we can get rid of the
problem for the future. I was thinking of something like:
apache2 contains the config and the init scripts.
apache2-bin contains all the binaries and provides apache2-
mmn-20120123 or whatever the module magic number will be in 2.4.
apache2-common (or apache2-data) would contain all the arch-
independent files (mostly icons and error documents, I guess). Module
packages would only depend on apache2-mmn-20120123. This would mean we
wouldn't need to rename packages if there is ever a 2.6 (and also not
when going from 2.3 in experimental to 2.4). There should be a script
or another easy way for module packages to add the correct dependency.
To get an idea about the woes of the 2.0 -> 2.2 upgrade, you should
probably look into the etch package and read the changelog.
Instead of defining lots of stuff in the envvars file and using that
in scripts and the config, it should be possible to get most infos
from the output of "apache2 -t -DDUMP_RUN_CFG" and use that in
scripts.
There are probably lots of other things, but these should be the most
important ones for the start.
I still think that collecting ideas and decisions on a wiki page would
be a good idea. Otherwise there is the danger that something gets lost
in long mailing list threads.
> >> Otherwise the repository looks good. pristine-tar is obviously
> >> broken for now but I think we can address that later.
> >
> > Can you elaborate? pristine-tar works for me.
>
> How? The branch is empty and does not contain any diffs. We would
> need to import released orig.tar.gz into pristine-tar to get it
> working. Not sure if it is worth the effort though. Maybe it is
> enough to start doing so from now on for upcoming imports.
You must have done something wrong. I get:
$ git log pristine-tar |head
commit 875c37bcd5837f49be2673407799b308e32c8c5b (origin/pristine-tar,
pristine-tar)
Author: Stefan Fritsch <sf@sfritsch.de>
Date: Tue Dec 27 19:43:24 2011 +0100
pristine-tar data for apache2_2.2.21.orig.tar.gz
commit 7bb2f1029634aa4cbeec151b2f0dfde31228f6c7
...
Cheers,
Stefan
Reply to: