Re: New selfcontained packaging for roundcube and guam

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)

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 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).

> 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.

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. :-(

best regards
hede