Hosting and Vcs-* fields in packages modified from Debian

[Robert Collins]

On Wed, 2008-08-20 at 22:51 +0200, Loïc Minier wrote:
> On Wed, Aug 20, 2008, Steve Langasek wrote:
> >                                  Ideally if the maintainer is already using
> > feature branches in a distributed VCS, Ubuntu could hook into that with its
> > own feature branches, and that would entirely satisfy my concerns about
> > maintainability of the patches.  But the highest percentage of Vcs-* fields
> > in Debian packages still point at subversion, which is not at all useful for
> > this purpose.
> 
>  Ah it's been a while I'm tempted to ask how other people deal with a
>  couple of issues I have on these topics...
> 
>  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.

>    I wonder about a couple of things:
> 
>  a) I don't have access to centralized hosting for e.g. git trees with
>     Launchpad's access control / unix permissions; ideally, we would
>     have the major services provided by Alioth on Launchpad to share
>     with various Ubuntu teams, but since we only have Bzr, it's not easy
>     to use other distributed VCSes for Ubuntu branches; it's not always
>     possible to import into Bzr, and it adds a conversion step (also it
>     makes it harder to pull the other way around)

It also lets us build toolchains on a single base, rather than on N
bases. So we can build to the strengths of bzr, rather than to the
smallest common subset of features different VCS systems have.

>       So where do you people host your branches?

Launchpad.

>        * I could push to say people.ubuntu.com/~lool, but then if I were
>          to declare this to be the location for the Ubuntu packaging
>          bits, I would have to act as a middleman before any update to
>          this tree.

You would also effectively be creating a maintainer lock, which is one
of the key differences between Debian and Ubuntu.

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

>        * I could ship the DVCS files in the source package itself, but
>          I understand it's still "future technology"

It also conflates build-this-software instructions and
manage-the-patches-for-upstream, which is quite a bit icky.

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

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20080821/b5652891/attachment.pgp