Ubuntu+eBox status

[Javier Uruen Val]

Hi there,

> Seeing as feature freeze is slightly less than a month away, I'd like to
> get a status update on your progress for eBox in Ubuntu.

Well,  we have ended up running behind schedule.  I have already packaged most 
of the eBox modules for Gutsy, you can take a look at the announcement here 
[0].

From the functional point of view there are just a few things left to polish 
in order to have a full-fledged eBox in Ubuntu or, at least, with the same 
functionality as our Debian based version. I will probably fix these issues 
next week.

From the Ubuntu packaging point view there are a few other things to work out. 
For example, I had to go back to apache 1.3. The reason was the large amount 
of memory used by apache2 + modperl + eBox in comparison with apache 1.3: at 
least more than 100M. And also some random weirdnesses we didn't have with 
the good-old apache. I backported an apache 1.3.34 package from Debian Etch 
while I track down the problems I've just explained.

We also ship a patched postfix. This patch [1] adds support for "soft quota".

There are a couple more of perl modules we have packaged: 
libnet-cups-perl-0.55 and libtree-perl-1.0.

There are a few other details I have changed based on your previous packaging 
work. I'll gather together these things and I'll email you. 

You have to keep in mind that we "relax" the Debian policy in some packages in 
order to have a working version ASAP. Our first goal was to have a working 
Ubuntu version which  can be released by us. 

Now that  we have most of it working smoothly we can pay more attention to the 
Ubuntu/Debian policy. And again, we as a project are *very willing* to fix 
whatever is needed to comply with the packaging policy.

[...]
>  * ebox-samba needs to follow the Debian policy for managing
>    configuration files. Among other things, this means that it must
>    preserve user changes to smb.conf. I'd like to get a status on that.

I haven't done anything about that yet. It's now when I'll have time to start 
with that. We have to decide what we want to do with this. Merging  eBox 
configuration with user configuration without an external tool which takes 
care of it can be very very tricky.

Another approach is detecting if the file which is going to be overwritten has 
been modified by the user, in that case the user would be informed and 
prompted to confirm changes or cancel. I guess that should be the way to go 
with every single configuration file overwritten by eBox from other packages.

My main concern here is not the implementation but the time frame and if we'll 
be ready for Hardy.


>  * ebox-printers needs to work with our current set of cups libraries.

This shouldn't be a problem as it's already working with the libraries shipped 
in Gutsy. 


> It would be lovely if we could get your current stuff packaged up and
> uploaded to universe, so that we can begin testing, so everything can be
> in good shape before release.

That would be cool.

> The status of this was requested at our community meeting yesterday, and
> I promised I'd CC the list on our correspondance, so please CC the list
> when you reply. If you're not subscribed to the list, I'll moderate your
> reply through. No worries.

No problem.



[0] http://forum.eboxplatform.com/index.php?topic=77.0
[1] http://vda.sourceforge.net/se.