[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Steps to follow to not break gitlab and diaspora when dependencies are updated



Hi,

On 15-06-16 08:34, Pirate Praveen wrote:
> Hi,
> 
> Background: recent update of ruby-addressable broke gitlab.
> 
> https://ci.debian.net/data/packages/unstable/amd64/g/gitlab/latest-autopkgtest/log.gz
> 
> Could not find gem 'addressable (~> 2.3.8)' in any of the gem sources
> listed in your Gemfile or available on this machine.

Doesn't this mean that the dependencies in the gitlab package are not
correct? It now states '>= 2.3.8', but this clearly doesn't correspond
to gitlab's actual dependencies in the Gemfile.

> Reason: Declaring tight dependency by gitlab and diaspora.
> 
> Root cause: There is no guarantee that minor updates won't introduce
> breaking changes.
> 
> Solution: Semantic Versioning.
> 
> Way out: We should follow these steps when either gitlab or diaspora
> appears in the reverse dependency of any update.
> 
>     If it is a major version update, then it should be uploaded to
> experimental first. Once compatibility with gitlab and diaspora is
> tested, it can be uploaded to unstable after relaxing gem dependency in
> their Gemfiles.
> 
>     If it is a minor version update and it is development version (>=
> 1.0), follow step 1 as there is no guarantee that minor versions will
> not introduce breaking changes.
> 
>     If the gem follows SemVer.org, the upstream guarantees to not
> introduce breaking changes in minor updates. Check list of upstreams
> committed to semver first. If an upstream has not pledged SemVer
> complaince, we should ask them to follow it and add it to the list.
> 
>     Check if the gitlab and diaspora versions in unstable allows the
> minor update from "Packaging Progress Statistics" at
> http://debian.fosscommunity.in/. If it allows the minor update (~> x.y),
> upload the new version to unstable.

If the package version dependencies would match the dependencies
declared in the Gemfiles, this check would be automatic, and Debian
could rely more on upstream dependency compatibility knowledge.

>     If it does not allow, relax the dependency in Gemfile and request
> upstream to relax the dependency so we don't have to maintain a patch.
> gitlab has been responsive to such requests, but diaspora has not been.
> 
> I have documented these steps here
> https://wiki.debian.org/Diaspora/Packaging/UpdateUpstream

Regards,
Matijs

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: