/breezy-debian/trunk

To get this branch, use:
bzr branch https://code.breezy-vcs.org/breezy-debian/trunk

« back to all changes in this revision

Viewing changes to specs/upstream-tarball-fetching

  • Committer: James Westby
  • Date: 2007-01-31 21:44:25 UTC
  • Revision ID: jw+debian@jameswestby.net-20070131214425-h03rjldy11fq0tl0
  * Start adding specs of things that I want to implement.
  * Start with tarball fetching, where a needed tarball can be downloaded
    automatically.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Fetching the upstream tarball from some other location
 
2
------------------------------------------------------
 
3
 
 
4
Status: Draft
 
5
 
 
6
Rationale
 
7
=========
 
8
 
 
9
For a user of the plugin who is using a non-bzr upstream mode, but is not
 
10
upstream they will have to get download the tarball from a website of FTP
 
11
site or similar.
 
12
 
 
13
In order to make moving to a new upstream version in this case easier
 
14
the plugin could look for the tarball in a remote location if it's not found
 
15
locally, then download it and place it locally.
 
16
 
 
17
It's not a huge win, but it does mean that if it is set up correctly a new
 
18
upstream just needs dch to try and test build.
 
19
 
 
20
Design
 
21
======
 
22
 
 
23
A new config variable 
 
24
 
 
25
tarball-fetch-location
 
26
 
 
27
that takes a URI to a directory that upstream uses for releases on a server.
 
28
 
 
29
When building a package it will look for the tarball in orig-dir. If it is
 
30
not found it will assume that it is a new release, and try and download the
 
31
tarball from tarball-fetch-location. If this fails then it will error out
 
32
as usual. If it suceeds the tarball will be placed in the build area. Also
 
33
the plugin will try and create orig-dir if it doesn't already exist, and try
 
34
and put it in there. This will save downloading each time (and the reason
 
35
for not supporting remote orig-dir). If it can't put the file there it will
 
36
just mention that and carry on, as we can assume that the user doesn't want
 
37
the cacheing.
 
38
 
 
39
Unsolved Problems
 
40
=================
 
41
 
 
42
There are two problems I envisage
 
43
 
 
44
1. The upstream provides a different format tarball.
 
45
 
 
46
This could be done later, but it would be easy to add auto-repacking of
 
47
at least .bz2 tarballs. However the naming differences lead to point 2.
 
48
 
 
49
2. The upstream has a different tarball name.
 
50
 
 
51
Debian has strict rules on the name of the tarball. Upstream wont follow this.
 
52
This means that builddeb needs to be able to infer the upstream tarball
 
53
name from the debian name (or the information).
 
54
 
 
55
There are a few alternatives as I see it.
 
56
 
 
57
  * Require the upstream name.
 
58
 
 
59
    Broken as it removes the generality of the solution.
 
60
 
 
61
  * Require a mapping from debian version etc. to upstream name.
 
62
 
 
63
    This seems best. The implementation needs some thought, as it needs to
 
64
    be flexible enough for correct specification but not overly complicated.
 
65
    For instance uscan already has this sort of thing, so perhaps use that,
 
66
    or even just parse debian/watch if present.
 
67
 
 
68
Code changes
 
69
============
 
70
 
 
71
Add support for the option.
 
72
Add command line option.
 
73
Add transports for at least HTTP and FTP.
 
74
Add name mangling support.
 
75
Change the error message for no tarball in orig-dir to mention this option.
 
76