RE: New selfcontained packaging for roundcube and guam

On Monday, 13 June 2022 15:30:32 CEST you wrote:
> Dear all,
> 
> first off, thank you all and I'm happy to hear there is some great new 
> development activity here. :-)
> I wish you all good luck with this.
> 
> Am 13.06.2022 10:40, schrieb Christian Mollekopf:
> > Hi,
> > 
> > To reduce packaging effort on new platforms roundcubemail and guam
> > have been turned into selfcontained packages that we'll use going
> > forward.
> 
>  From the kolab development point of view this is probably fine if the 
> goal is to get installed on dedicated machines alone and not to provide 
> a base for potential upstream maintainers. (Sorry for this ironic 
> comment)

That's the tradeoff, yes.

> Then providing a container-image only (and no packages for general 
> operating systems) is probably even more "reduction in complexity of the 
> packaging itself". (as a serious meant suggestion)

We have seriously been contemplating this, but we need packages for the time being.

> > We wouldn't strictly have to replace those packages, but we currently
> > conflict with files (could be improved in the packaging).
> 
> I would suggest splitting up the packages. That's a well-established 
> concept. *SCNR*
> 
> Replacing existing files with packages named after the system-included 
> packages - this way even dependencies for other non-related system 
> packages depending on the now obsolete system packages can get can 
> resolved to your new packages. Best way if you want to extend 
> development in future and not stay in the present.
> 
> If you don't want to walk this well-established way, please install your 
> self-contained and potentially conflicting packages to /opt (or even 
> /usr/local, while I think /opt is better suited here).
> Directories like /usr/share and /usr/lib are directories for packages 
> respecting the system policy (like found in the Debian Policy Manual for 
> Debian packages).

Yes, the vendorized files shouldn't end up in a shared location.

> > I understand if this is not everyones preferred method,
> 
> yep, but this is a free world and I think "those who do the work can 
> decide how it's done" :-)
> 
> > but with
> > recent distributions lacking a lot of the dependencies that we
> > traditionally require,
> > and a vast reduction in complexity of the packaging itself, I hope you
> > can understand why this is happening.
> 
> I can understand it, but I think you blaze the way for some conflicts in 
> the future this way. Yet this could probably still be less work than to 
> "make it right by now". Thus, go your own way. :-)
> 
> > To opt-out a separate branch project on the OBS would have to be
> > maintained where the *-selfcontained packages could be disabled.
> > Please note that the traditional packages will no longer receive
> > updates from our side.
> 
> That's absolutely understandable, I think.
> 
> > I tried making sure that all package managers automatically upgrade to
> > the new packages, but it's of course possible that I missed some
> > upgrade scenarios that could be solved better, help is welcome.
> 
> At least for my Debian 10 I had some difficulties with the roundcubemail 
> package (I had to manually remove the old ones) and the guam package is 
> still on 0.9.11-1, not automatically updated even there is a candidate 
> version 0.9.12-1 available.

Ok, I'll have to look into that.

> Maybe we can meet to discuss the possibility if I would like to maintain 
> my own branch of a Debian packages stack. But unfortunately this 
> currently is out of discussion for me as I do not have the time. :-(

I'm happy to have a discussion in any form (mail, videoconference, ...)

Thanks for your feedback!

Cheers,
Christian