State of Roundcube packaging in Debian?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

State of Roundcube packaging in Debian?

Dominik George-4
Hi,

I found out today that roundcube was removed from Debian testing due to
some unfixed bugs. I investigated a bit further and found that:

 - 1.1.0 has long been released upstream, but:
    - the watch file never picked it up, and
    - the package VCS is stuck at an unreleased 1.0.0
 - A partially fixed package was uploaded to unstable in January,
   but was not unblocked, and
    - is not in the package VCS

Could you please elaborate a bit on the state of Roundcube in Debian,
and what I (or others) could do to get it straight again?

Cheers,
Nik

--
Dominik George (1. Vorstandsvorsitzender, Pädagogischer Leiter)
Teckids e.V. - Erkunden, Entdecken, Erfinden.
https://www.teckids.org


signature.asc (906 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

Vincent Bernat-3
 ❦ 14 mars 2015 11:11 +0100, Dominik George <[hidden email]> :

> I found out today that roundcube was removed from Debian testing due to
> some unfixed bugs. I investigated a bit further and found that:
>
>  - 1.1.0 has long been released upstream, but:
>     - the watch file never picked it up, and
>     - the package VCS is stuck at an unreleased 1.0.0
>  - A partially fixed package was uploaded to unstable in January,
>    but was not unblocked, and
>     - is not in the package VCS
>
> Could you please elaborate a bit on the state of Roundcube in Debian,
> and what I (or others) could do to get it straight again?
The package is team-maintained but none of the maintainers have time to
take care of Roundcube. Hence, the removal from Jessie. The main
difficulty is to handle the 0.9.5 to 1.x upgrade where the configuration
files change.

It is unlikely anything will happen until a new maintainer steps in the
team. I have written this just today:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752479#68

The upload in unstable without being in the VCS is just that I don't
want to spend unecessary time to understand how to handle correctly the
exclusion of (unused) non-DFSG files with gbp. Maybe that's just a
matter of using --uscan. Maybe not.
--
Each module should do one thing well.
            - The Elements of Programming Style (Kernighan & Plauger)

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

John Goerzen-3
On 03/14/2015 07:36 AM, Vincent Bernat wrote:

>  ❦ 14 mars 2015 11:11 +0100, Dominik George <[hidden email]> :
>
>> I found out today that roundcube was removed from Debian testing due to
>> some unfixed bugs. I investigated a bit further and found that:
>>
>>  - 1.1.0 has long been released upstream, but:
>>     - the watch file never picked it up, and
>>     - the package VCS is stuck at an unreleased 1.0.0
>>  - A partially fixed package was uploaded to unstable in January,
>>    but was not unblocked, and
>>     - is not in the package VCS
>>
>> Could you please elaborate a bit on the state of Roundcube in Debian,
>> and what I (or others) could do to get it straight again?
> The package is team-maintained but none of the maintainers have time to
> take care of Roundcube. Hence, the removal from Jessie. The main
> difficulty is to handle the 0.9.5 to 1.x upgrade where the configuration
> files change.
I assume you mean the config files change in some dramatic way; that is,
some way that means the existing files won't work anymore?

If that is the case, why does this have to be a big deal?  Couldn't you
just warn people that the upgrade will break their config, point them to
the docs, and call it good?  After all, if that is all upstream
provides, isn't it better than nothing?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/5505EDAF.1040705@...

Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

Christian Kastner-4
On 2015-03-15 21:38, John Goerzen wrote:

> On 03/14/2015 07:36 AM, Vincent Bernat wrote:
>> The main difficulty is to handle the 0.9.5 to 1.x upgrade where the
>> configuration files change.
> I assume you mean the config files change in some dramatic way; that is,
> some way that means the existing files won't work anymore?
>
> If that is the case, why does this have to be a big deal?  Couldn't you
> just warn people that the upgrade will break their config, point them to
> the docs, and call it good?  After all, if that is all upstream
> provides, isn't it better than nothing?

Another alternative would be to not implement the upgrade path at all,
and provide a separate roundcube-1.1 package instead, for those willing
to do the migration manually (which I'd argue is a low price to pay).

Package roundcube could become a meta-package and depend on whatever the
latest version of roundcube-X.Y is for which an automatic upgrade path
is provided, so it would start of depending on the current roundcube-0.9
and when/if the automatic upgrade path to roundcube-1.1 becomes
supported, bump the dependency to that.

Regards,
Christian


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/55060897.1010808@...

Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

Cameron Norman
On Sun, Mar 15, 2015 at 3:32 PM, Christian Kastner <[hidden email]> wrote:

> On 2015-03-15 21:38, John Goerzen wrote:
>> On 03/14/2015 07:36 AM, Vincent Bernat wrote:
>>> The main difficulty is to handle the 0.9.5 to 1.x upgrade where the
>>> configuration files change.
>> I assume you mean the config files change in some dramatic way; that is,
>> some way that means the existing files won't work anymore?
>>
>> If that is the case, why does this have to be a big deal?  Couldn't you
>> just warn people that the upgrade will break their config, point them to
>> the docs, and call it good?  After all, if that is all upstream
>> provides, isn't it better than nothing?
>
> Another alternative would be to not implement the upgrade path at all,
> and provide a separate roundcube-1.1 package instead, for those willing
> to do the migration manually (which I'd argue is a low price to pay).

I do not think it wise to package every point release since roundcube
does not intend to break the configs every point release as they did
in version 1. However packaging a roundcube-1 is useful IMO (and it
would be version 1.0 then 1.1 then 1.2 etc.).

Cheers,
--
Cameron Norman


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/CALZWFRJQexvstsCv3a+KdsR0AUYq0HLcNQAaKeVhekCRTC735g@...

Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

Paul Wise via nm
In reply to this post by John Goerzen-3
On Mon, Mar 16, 2015 at 4:38 AM, John Goerzen wrote:

> If that is the case, why does this have to be a big deal?  Couldn't you
> just warn people that the upgrade will break their config, point them to
> the docs, and call it good?  After all, if that is all upstream
> provides, isn't it better than nothing?

If upstream wants to fix this, Elektra or Config::Model could be a good choice.

https://github.com/ElektraInitiative/libelektra
https://github.com/dod38fr/config-model/wiki

--
bye,
pabs

https://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/CAKTje6Ga6=wmkXZaxKXZmVyyQHmj5CpK3tDrpPoh5gQgZZuvNA@...

Reply | Threaded
Open this post in threaded view
|

Re: State of Roundcube packaging in Debian?

Vincent Bernat-3
In reply to this post by John Goerzen-3
 ❦ 15 mars 2015 15:38 -0500, John Goerzen <[hidden email]> :

>>> I found out today that roundcube was removed from Debian testing due to
>>> some unfixed bugs. I investigated a bit further and found that:
>>>
>>>  - 1.1.0 has long been released upstream, but:
>>>     - the watch file never picked it up, and
>>>     - the package VCS is stuck at an unreleased 1.0.0
>>>  - A partially fixed package was uploaded to unstable in January,
>>>    but was not unblocked, and
>>>     - is not in the package VCS
>>>
>>> Could you please elaborate a bit on the state of Roundcube in Debian,
>>> and what I (or others) could do to get it straight again?
>> The package is team-maintained but none of the maintainers have time to
>> take care of Roundcube. Hence, the removal from Jessie. The main
>> difficulty is to handle the 0.9.5 to 1.x upgrade where the configuration
>> files change.
> I assume you mean the config files change in some dramatic way; that is,
> some way that means the existing files won't work anymore?
Yes.

> If that is the case, why does this have to be a big deal?  Couldn't you
> just warn people that the upgrade will break their config, point them to
> the docs, and call it good?  After all, if that is all upstream
> provides, isn't it better than nothing?

Upstream provides a conversion script. But, yes, we could put the
upgrade burden on the user, this is better than no upgrade.

The bottom line is the maintainers don't have time. It is unclear if
orphaning works for a team-maintained package. People propose to help
From time to time, then usually disappear. Someone just proposed to help
(Sandro). Maybe this will help push 1.1.0.

The packaging is not utterly complex but not trivial (dbconfig-common
handling, ucf-managed configuration files, some debconf questions,
embedded code removal, DFSG tarball needed for political reasons).

Also, security handling is difficult because Roundcube is exposed to a
class of attacks (script injection and CSRF) that are usually fixed by
applying large patches difficult to backport. Even when the patch
applies on older versions, we really don't know if it is complete for
the older version.
--
Write clearly - don't sacrifice clarity for "efficiency".
            - The Elements of Programming Style (Kernighan & Plauger)

signature.asc (834 bytes) Download Attachment