Hosting and Vcs-* fields in packages modified from Debian

Loïc Minier loic.minier at ubuntu.com
Fri Aug 22 12:03:07 BST 2008


On Thu, Aug 21, 2008, Robert Collins wrote:
> >  I personally try to use the same type of VCS that upstream is using for
> >  the packaging bits I maintain [1]: I can merge from upstream and keep a
> >  common history.
> 
> Given that there is only one VCS really supporting cherry picking today
> (darcs), and many upstream releases are not accurately represented in
> tarballs (due to e.g. configure, Makefile.in etc), I'm not sure how much
> of a common history you really get. Certainly with svn/cvs/other
> centralised system you won't get any common history. Its true that the
> closer the connection the easier things get. I would get LP to import
> and svn/cvs upstream though, and bzr-git is coming along quite well at
> the moment.

 Hmm importing remains an additional step which I could bear, but I
 wouldn't be able to offer my work back as a git tree to e.g. upstream
 or Debian.  Or: were I to develop a feature in a branch or prepare a
 new upstream ahead of Debian in an Ubuntu bzr-git imported repo, how
 would they pull back in their git tree?

> >        * I could push to Alioth [2], but it's disturbing for many
> >          reasons:
> >          - not all Ubuntu people have accounts, and we would miss the
> >            groups anyway
> >          - use of Debian resources for Ubuntu; I feel I need permission
> >            of the packaging project I'm forking from; not really
> >            possible for packages in Ubuntu alone
> >          - causes a dependency between Ubuntu data and Debian
> >            infrastructure: e.g. Alioth is down and you can't commit  :-/
> The primary problem here is introducing skew between the packaging
> branch and the uploaded-to-Ubuntu packaging - that would occur if Alioth
> were down and you needed to get stuff built.

 Exactly; even more disturbing if we consider a future where we push to
 a DVCS branch to upload a new revision of a source.  If we imagine that
 I could point LP at a remote DVCS where I push new versions of the
 package to push into Ubuntu (with GPG signing and all), then an Alioth
 downtime might prevent uploading new packages to Ubuntu.  (Granted,
 this is very hypothetical.)

> >  b) we seem to lack clear/strict guidelines for dealing with Debian
> >     versus Ubuntu versus upstream Vcs information; I think we need more
> >     tools, more policies, and more documentation for this issue:
> >     - we should clear Vcs-* fields when forking a package for Ubuntu
> >       which was kept in a Vcs when we don't intend to keep it in a Vcs
> >       (examples of packages getting this wrong: pbuilder, xorg-server)
> >       -- or rename them to X(S)-Original-Vcs-* -- or mention the Ubuntu
> >       Vcs instead
> >     - we should update tools such as "update-maintainer" to do the right
> >       thing
> >     - we could enhance the Vcs-* policies/specs to cover upstream
> >       information and perhaps improve the "X*-Original*" policies/specs
> >       to handle multiple levels of forking (package forked from maemo
> >       into Debian, and then forked from Debian into Ubuntu for instance
> >       :-)
> You should probably read the Ubuntu Distributed Development pages :).

 These pages cover some interesting processes for future technologies
 which would probably make my questions obsolete, but I feel like we
 could improve the present situation with some not too complex
 extensions of the meta-information we have in source packages -- such
 as the above proposals, or simply providing things like the branch to
 checkout from a Vcs-Git repo for example.

 I do look forward to distributed development though :)

-- 
Loïc Minier



More information about the ubuntu-devel mailing list