Quoting gregor herrmann (2013-12-23 04:06:30)
> "Makes [git] easy" seems to be true, even if it takes a few more
> steps, as described on e.g.
> https://wiki.debian.org/CDBS+git-buildpackage
>
> git remote add upstream-repo ${upstream_git_url}
> git fetch upstream-repo
> git-import-orig --pristine-tar --sign-tags --upstream-vcs-tag=${tag} ${path-to-fetched-tarball}
>
> Nice so far; except that a simple `git-import-orig --pristine-tar
> --uscan' doesn't work anymore :/ (Or does it? But even then, manually
> specifying tag names seems like a regression in comfort to me.)
Nowadays git-buildpackage supports tracking a) only upstream tarball, b)
only upstream git, or c) both upstream tarball and upstream git.
For packages maintained tracking both upstream tarball and upstream git
(via --upstream-tag option and tarball path), it works fine that e.g. an
NMU is done tracking only upstream tarball (via --uscan option):
tracking of git for that specific upstream release/snapshot can simply
be skipped, or (if done before progressing further on upstream branch)
same upstream release/snapshot can be re-applied later by simply running
the git-import-upstream command again.
Is that what you were uncertain if still works?
Regarding the comfort, it should be relatively easy to make a wrapper
script that checks if a tags exists matching the to-be-imported version,
and suggests to include that tag.
Here's the almost-working script I currently use in my mc (Midnight
Commander) menu file:
set -e
set -x
set -o pipefail
pkg="$(dpkg-parsechangelog | egrep '^Source:' | cut -f 2 -d ' ')"
uscan="$(uscan --report-status || true)"
uversion="$(echo $uscan | perl -nE '/remote site is ([^\s,]+)/ and say $1')"
dversion="$(echo $uscan | perl -nE '/local version is ([^\s,]+)/ and say $1')"
utag="$(git tag | grep -x "$uversion" || git tag | grep -x "v$uversion" || git tag | grep -- "-$uversion\$")"
debian/rules get-orig-source DEB_UPSTREAM_TARBALL_VERSION="$uversion" DEB_UPSTREAM_TARBALL_MD5=
git-import-orig --pristine-tar --sign-tags --filter=.gitignore ${utag:+--upstream-vcs-tag="$utag"} "../tarballs/${pkg}_${dversio
> Ok, next problem: Unless I'm mistaken, which might very well be the
> case, the "local" remotes are not pushed, so no one else will know
> that I added this nice upstream-repo remote.
the _content_ of the "upstream-repo" remote is located upstream. I see
no reason for us to mirror that branch: Anyone wanting to import can
fetch that git branch from upstream (exactly as we do with tarballs!).
> Which means, as a first step, if we want to go into this direction,
> that we'll need the upstream git URL somewhere in the package/repo.
Right, the _URI_ of the "upstream-repo" remote we should register.
> A possible solution might be DEP12/UMEGAYA, the spec for a
> debian/upstream file.
>
> http://dep.debian.net/deps/dep12 (dead right now
Seems not even created there (yet?): http://dep.debian.net/deps/
> but this works:
> http://anonscm.debian.org/viewvc/dep/web/deps/dep12.mdwn?view=markup )
> http://wiki.debian.org/UpstreamMetadata
>
> This spec has all kinds of interesting fields, among them Repository.
> (And also things like Bug-Submit which we might want to use in `dpt
> forward-{bug,patch}. Oh, and they probably also need github support.
> But I digress.)
All that is needed as I see it is a URL usable for "git clone".
Copyright file format 1.0 supports multiple URLs in Source: header
field. My current practice is to look for git:// URLs there.
So no need to introduce new metadata file for most common needs.
Some gits may be served only with http:// URLs that cannot be
distinguished that easily, but I suspect that's a minority of cases.
> Ok, so we can [store the git hint somewhere with] the repository URL
> for the remote. And how does the value get there? CPAN::META::Spec has
> a resources field with exactly this information (and other intersting
> stuff, like bugtracker), and all newer META.{yml,json} files actually
> provide it, at least in my experience.
>
> https://metacpan.org/pod/CPAN::Meta::Spec#resources
>
> So it shouldn't be too hard to get the information from META.yml in
> the distribution into debian/upstream (YAML) in our package. (Not only
> for the repository URL but also for all other mapable fields, if we're
> there.)
>
> I guess this could be added to dh-make-perl or dpt-package-check or
> somewhere else.
Beware that some upstreams use and promote git but has it structured
differently from one-git-equals-one-source-tarball which is the only
structure supported by git-import-orig currently.
E.g. RDF::Trine, RDF::Endpoint and a few more all declare
http://github.com/kasei/perlrdf/ as their repository - where each module
is a subdirectory.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature