On Wed, Jun 15, 2016 at 12:04:24PM +0530, 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. > > 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 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 I suffered with this for a long time with rails, vagrant, and redmine, and maybe others, and realized that it's easier to just relax the dependencies in the metadata with a Debian-specific patch and follow up to actual breakage (tests, bug reports, etc), than to stick to such strict dependencies. My general approach is to simplify ~> x.y.z to ~> x.y, and assume that the upstream maintainers of the dependencies are not insane, even if they didn't explicitly stated that they "follow SemVer". This mostly works. Expecting the whole archive to align exactly right with the original metadata in these packages with insane dependency trees is pretty unrealistic. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: PGP signature