WebGUI and Debian Squeeze
I've been packaging WebGUI  for over two years , maintaining
unofficial packages for Debian Lenny until it was impossible to run
WebGUI on it due to dependencies. Gregor (gregoa) has been my upload
sponsor and packaging mentor, while Colin has been the main point of
contact with upstream, having helped with bugfixes and several
enhancements that have made WebGUI more suitable for Debian packaging.
The Squeeze freeze happened just a few days before webgui 7.9 was
released as stable, and 7.8.24-1 was included in Squeeze a few days
later. There will be no 7.8.25, since upstream's development cycle is a
steady and goal-oriented one, and once a version is deemed stable, the
previous one isn't developed nor updated any more. In the past, I've
always waited for the development version to become stable before
transitioning the package (7.5 to 7.6, 7.6 to 7.7 and 7.7 to 7.8); I
feel it's important for the release team to know, what I've found out in
practice and Colin can confirm: transitions from minor WebGUI versions
(e.g. 7.N to 7.N+1) are completely smooth due to the way upgrades are
handled by WebGUI and the Debian package uses it.
It's been a week since I finished the packaging transition to 7.9 (it's
still marked as UNRELEASED in collab-maint SVN) closing three packaging
bugs along the way (593885, 593698 and a non-reported bug I was waiting
to fix). I've also tried to simplify debian/rules but several
shortcomings in dh_fixperms (bug filed) prevent me from getting rid of
the explicit find-chmod combinations (they have been there and work
fine, I just wanted to get rid of them).
Now, following WebGUI's development cycle, 7.8 is now deprecated and one
should be using 7.9 for the following 6-8 months before 7.10 is
released. Upstream won't fix bugs you detect on 7.8 unless they show up
in 7.9 too, and they fix them in 7.10/7.9 but the fixes aren't
backported. This means that having 7.8.24 in Squeeze would mean having
an already old version of the application.
There have been several _potential_ security issues in all the 7.x
releases before 7.9 that have been addressed and fixed but cannot be
backported to 7.8 because of structural changes in WebGUI. That's one of
the reasons why an upgrade to 7.9 is mandatory. Colin has offered to
grant access to the bug reports that show the potential vulnerabilities
and explain the fact that they can't be backported to 7.8.
As is usual with WebGUI and the current Debian package, the upgrade from
7.8 to 7.9 is flawless and I've tested it thoroughly. For the first
time, the codebase testing routines provided by WebGUi (over 20000
tests) complete successfully even under the stressful code coverage and
"live system tests". Finally, the packaging bugs I fixed provide
stricter FHS compliance and address some borderline upgrade cases that
prevented clean upgrades. This is the first time Debian Stable will have
a webgui package, and I think Squeeze should be released with a current,
safe to use, and easily upgradeable version of WebGUI, and that would be
the current 7.9.13 package.
FWIW, I have a couple of _production_ installations with the same 7.9.13
package running on Squeeze (with a couple of locally built dependencies,
more on that later) that have been working flawlessly for a couple of
weeks now under heavy load and even with local customization.
So I'm requesting a freeze exception (actually three) in order to get
webgui 7.9.13 into Debian Squeeze. The exception would include two
dependencies already in NEW, packaged by me and maintained under the
Debian Perl Group, again being nitpicked by gregoa, dam and ansgar:
liblog-any-adapter-dispatch-perl and libchi-perl. Finally, the exception
for webgui 7.9.13-1 proper, that will be uploaded only if the exception
I apologize for having waited this much to ask for the freeze, but I
wanted to be sure that everything was working properly. Thank you for
your time and effort.
Ernesto Hernández-Novich - @iamemhn - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3