1 |
Am Freitag, den 05.02.2010, 11:34 +0100 schrieb Alexis Ballier: |
2 |
> > Other sites I'd like to add: |
3 |
> > - pypi |
4 |
> > - google-code |
5 |
> > - ctan ... if someone can identify a key for packages |
6 |
> |
7 |
> I don't know what you exactly mean by a key, but for ctan the |
8 |
> catalogue [1,2] may be what you're looking for. |
9 |
> If I understood correctly, a key would be $PN and the relevant |
10 |
> information found in, e.g., |
11 |
> http://texcatalogue.sarovar.org/entries/${PN}.html |
12 |
> |
13 |
> Note that not all packages have version information; if they don't, one |
14 |
> can probably use the date instead. |
15 |
Last time I checked I didn't have the impression that ${PN} is not |
16 |
enough to get a unique entry for a package on ctan. |
17 |
|
18 |
> |
19 |
> If I remember correctly, texlive has perl scripts/libs to deal with it, |
20 |
> so it may be possible to reuse them for a bumpchecker. |
21 |
> |
22 |
> Also, definitely +1 for adding more sites, but I think one important |
23 |
> feature is missing: simple http/ftp listing. Not all projects are |
24 |
> hosted on major sites, and having a (more complicated) way of tracking |
25 |
> versions based on a directory listing could be useful. |
26 |
Definitely, but for http/ftp listing checks SRC_URI is probably enough. |
27 |
The only thing which could make it easier is when upstream uses |
28 |
sub-directories for major/minor versions (like gnome for example). In |
29 |
that case something like <remote-id |
30 |
type="ftp">http://ftp.gnome.org/pub/GNOME/sources/GConf</remote-id> |
31 |
might help to find a new version easier, but I really doubt it. |
32 |
|
33 |
But for now I'd stick to the two cases: |
34 |
a) hosting sites with project numbers/ids/names where we can extract |
35 |
version information in a general way |
36 |
b) arbitrary download sites, in which case a bump checker could try to |
37 |
find new versions by checking for a http/ftp listing or by checking the |
38 |
Changelog (<changelog>...</changelog>) which may also be a good way to |
39 |
know whether something changed at upstream (and then let the developer |
40 |
decide what it was) |
41 |
|
42 |
> I do not know |
43 |
> how to exactly implement that (maybe a regexp to match only the files |
44 |
> we want and a sed/awk script to do the $tarball -> $PV pass). |
45 |
> If I remember correctly debian has something like that for version |
46 |
> tracking, so it may be worth having a look. |
47 |
> |
48 |
> Alexis. |
49 |
> |
50 |
> [1] http://dante.ctan.org/tex-archive/help/Catalogue/catalogue.html |
51 |
> [2] http://texcatalogue.sarovar.org/ |
52 |
|
53 |
|
54 |
|
55 |
-- |
56 |
Tiziano Müller |
57 |
Gentoo Linux Developer |
58 |
Areas of responsibility: |
59 |
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor |
60 |
E-Mail : dev-zero@g.o |
61 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |