Post 3.2 Kopete and packagers

[Chris Cheney]

On Sat, Nov 29, 2003 at 07:39:52PM +0000, Richard Smith wrote:
> On Saturday 29 November 2003 6:06 pm, Matthias Welwarsky wrote:
> > Think: some application in kdenetwork has a security bug and distributions
> > ship out updated packages. Users install them, thereby downgrading kopete
> > to the version that came with the distribution. If kopete was in a package
> > of its own, it'd be up to the user to decide if he installed the
> > distributed version or something compiled from source.
> 
> If some app in kdenetwork has a security bug, *just* that app should be 
> updated IMO. If not, I'd say that your packages are too monolithic. I don't 
> see why you can't just package all kde apps seperately, independently of the 
> modules they're in. Otherwise, users should *expect* to have to update all of 
> kdenetwork whenever, for instance, some minor mispackagement is noticed, or a 
> security bug is fixed, or the MSN protocol changes.

Are you actually aware of what this involves, or does it just sound like
a good idea to you so you think it should be done... To properly package
KDE would require that KDE be developed properly as well, not in
monolithic modules/tarballs.  Yea, I agree that KDE being so monolithic
isn't a particularly good thing, since it also creates more burden on
packagers having to maintain a big chunk of KDE they potentially don't
even use, and have no interest in. It also leads to bad practices being
adopted such as KDE having autogenerated configure.ac files which cause
the sources not to be properly cleaned (make clean fails to clean), etc.
From a distribution maintainer point of view splitting the packaging of
KDE tarballs would require a lot of work, you would either need to
maintain the integrity of the source tarball which would duplicate the
size of eg kdenetwork from being ~ 6MB to being ~ 100MB (depending on
how many programs are split out into separate packages). The other
maintainer alternative would be to split the source tarball and only
have the needed files in each packages source. This would require the
maintainer to know quite a bit about how each program works so they
can properly prune the source to the minimum needed for each program.

> If you're prepared to release a new whatever due to a security hole (ie 
> because the package can no longer safely be used), you should also do so due 
> to a protocol change (ie because the package can no longer be used at all).

Releasing just part of a source package is not what is normally done for
security updates (at least in Debian's case).

> For people building from source, it makes a lot of sense to have KDE organised
> as it currently is (it makes compiling and installing so much easier). But 
> having kde{multimedia,graphics,network,etc} packages in a distribution, or 
> having some other way of organising KDE, is really a decision for KDE's 
> packagers to make; on the one hand, a kdenetwork package makes it easy to 
> install lots of related packages at once, but on the other hand, if one 
> package has a trivial change (or a security patch, or important bugfix, 
> or...) users have to get the whole thing again. This problem is not 
> Kopete-specific.

Oops I didn't see this before writing the above. :)

> I think the solution is to use metapackages (see how Chris Cheney packages KDE
> for Debian for an example). This seems to have no drawbacks, except on 
> distributions which don't support them (where they can be replaced by a 
> shell-script).

Splitting KDE back out into its true components like that other desktop
system would be ideal since it would allow finer grain maintainence. We
should probably wait until KDE 4 for this since KDE 3.2 is due for
release in 2 months. However, if anyone really wants to try this for
KDE 3.2 (hah) I will be more than willing to offer any help that I can. 

> To sum up (sorry for the long email):
> 
> I think kopete should be in kdenetwork, for consistency with the rest of KDE, 
> publicity, ease of building from source and so forth (since it's hopefully 
> going to become a well-integrated part of the desktop).
> 
> I see no technical reason why interim releases to make protocols work again 
> should give packagers more or fewer headaches than interim security releases. 
> In fact, I see no technical reason why it should be difficult at all, except 
> for monolithic KDE packages (which I consider broken anyway).

Agreed.


Chris