New selfcontained packaging for roundcube and guam

Daniel Hoffend dh at dotlan.net
Mon Jul 4 00:21:09 CEST 2022


Hi

I can understand your decisions when it comes to dependency hell of php, 
python, erlang, javascript and other projects that heavyly rely on 
external additional packages.

But the "skins" is something I would like to see kept seperate. For my 
installations I usually take the debian source skin package, change the 
colors (in _variables.less), add a logo, rename the package and rebuild 
and I'm done (1 short bash script). The new structure would likely work 
as well, but would be a bit more work

The next time I've to update, I'll take a closer look on what things break.

I'll have to take a closer look at my ansible role later.


Regards
Daniel



Am 13.06.2022 um 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.
> You may already have noticed this if you are using the Kolab:16 repository directly from the OBS.
> 
> For roundcube that means that roundcubemail-1.5.2 replaces:
> * roundcubemail-plugins-*
> * roundcubemail-skins-*
> 
> The buildroundcubemailtarball.sh script now assembles a tarball that includes the plugins and skins and is checked into the OBS.
> 
> 
> For guam-0.9.12 the erlang dependencies are vendorized, and on debian we currently replace:
> * erlang-eimap
> * erlang-goldrush
> * erlang-lager
> * erlang-syslog
> 
> We wouldn't strictly have to replace those packages, but we currently conflict with files (could be improved in the packaging).
> 
> 
> I understand if this is not everyones preferred method, 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.
> 
> 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.
> 
> 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.
> 
> Cheers,
> Christian
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users


More information about the users mailing list