Upstream tags in metadata.xml (GLEP 46)
 

While some people already discovered the upstream metadata tags, there
are only 8 ebuilds using them so far. Mostly I am to blame for that,
since I forgot to send out a proper announcement. While all the required
information can be found in the Developer Handbook [1], here is a short
summary:

The upstream tags are meant as a way to track information about
upstream, like:
- the upstream status (can make treecleaners lives easier)
- online documentation links (a shortcut for the user)
- not-so-obvious contact/bug-reporting information
- id of a hosting or indexing site (automated version bump checks)
- their alignment (mostly chaotic-neutral ;-)

An example (copied from GLEP 46 [2] itself):
<upstream>
<maintainer status="inactive">
<name>Foo Bar</name>
<email>foo@bar.bar</email>
</maintainer>
<maintainer status="active">
<name>Foo Gentoo</name>
<email>foo@gentoo.org</email>
</maintainer>
<changelog>http://foo.bar/changelog.txt</changelog>
<doc lang="en">http://foo.bar/doc/index.html</doc>
<doc lang="de">http://foo.bar/doc/index.de.html</doc>
<bugs-to>https://bugs.foo.bar</bugs-to>
<remote-id type="freshmeat">foobar</remote-id>
<remote-id type="sourceforge">foobar</remote-id>
</upstream>

Please note:
- the <maintainer> tag in <upstream> is only for specifying an upstream
maintainer name and e-mail address and does not specify the ebuild
maintainer (although it may be the same if you decide to become
upstream).
- the type attribute for <remote-id> is currently one of (freshmeat|
sourceforge|cpan|vim), send a mail to gentoo-dev before adding
additional sites
- the data in the <remote-id> tags is an id which uniquely identifies
the project on that site:
- for type="vim": the script_id (example: 2586)
- for type="freshmeat": the project name (example: aria2)
- for type="sourceforge": the project name (example: liferea)
- for type="cpan": the module name (example: Pod-Index)

Regards,
Tiziano



[1]:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
[2]: http://www.gentoo.org/proj/en/glep/glep-0046.html


--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

Upstream tags in metadata.xml (GLEP 46)
 

Am Donnerstag, den 04.02.2010, 22:37 +0100 schrieb Tiziano Müller:
> While some people already discovered the upstream metadata tags, there
> are only 8 ebuilds using them so far. Mostly I am to blame for that,
> since I forgot to send out a proper announcement. While all the required
> information can be found in the Developer Handbook [1], here is a short
> summary:
>
> The upstream tags are meant as a way to track information about
> upstream, like:
> - the upstream status (can make treecleaners lives easier)
> - online documentation links (a shortcut for the user)
> - not-so-obvious contact/bug-reporting information
> - id of a hosting or indexing site (automated version bump checks)
> - their alignment (mostly chaotic-neutral ;-)
>
> An example (copied from GLEP 46 [2] itself):
> <upstream>
> <maintainer status="inactive">
> <name>Foo Bar</name>
> <email>foo@bar.bar</email>
> </maintainer>
> <maintainer status="active">
> <name>Foo Gentoo</name>
> <email>foo@gentoo.org</email>
> </maintainer>
> <changelog>http://foo.bar/changelog.txt</changelog>
> <doc lang="en">http://foo.bar/doc/index.html</doc>
> <doc lang="de">http://foo.bar/doc/index.de.html</doc>
> <bugs-to>https://bugs.foo.bar</bugs-to>
> <remote-id type="freshmeat">foobar</remote-id>
> <remote-id type="sourceforge">foobar</remote-id>
> </upstream>
>
> Please note:
> - the <maintainer> tag in <upstream> is only for specifying an upstream
> maintainer name and e-mail address and does not specify the ebuild
> maintainer (although it may be the same if you decide to become
> upstream).
> - the type attribute for <remote-id> is currently one of (freshmeat|
> sourceforge|cpan|vim), send a mail to gentoo-dev before adding
> additional sites
> - the data in the <remote-id> tags is an id which uniquely identifies
> the project on that site:
> - for type="vim": the script_id (example: 2586)
> - for type="freshmeat": the project name (example: aria2)
> - for type="sourceforge": the project name (example: liferea)
> - for type="cpan": the module name (example: Pod-Index)

Other sites I'd like to add:
- pypi
- google-code
- ctan ... if someone can identify a key for packages

Opinions?

Cheers,
Tiziano

--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

Upstream tags in metadata.xml (GLEP 46)
 

On Thursday 04 February 2010 16:37:01 Tiziano Müller wrote:
> While some people already discovered the upstream metadata tags, there
> are only 8 ebuilds using them so far. Mostly I am to blame for that,
> since I forgot to send out a proper announcement. While all the required
> information can be found in the Developer Handbook [1], here is a short
> summary:

anyone who feels like doing this kind of work should feel free to add any
<upstream> tags to base-system/toolchain/games packages ... no need for
bugzilla and such.
-mike

Upstream tags in metadata.xml (GLEP 46)
 

> Other sites I'd like to add:
> - pypi
> - google-code
> - ctan ... if someone can identify a key for packages

I don't know what you exactly mean by a key, but for ctan the
catalogue [1,2] may be what you're looking for.
If I understood correctly, a key would be $PN and the relevant
information found in, e.g.,
http://texcatalogue.sarovar.org/entries/${PN}.html

Note that not all packages have version information; if they don't, one
can probably use the date instead.

If I remember correctly, texlive has perl scripts/libs to deal with it,
so it may be possible to reuse them for a bumpchecker.

Also, definitely +1 for adding more sites, but I think one important
feature is missing: simple http/ftp listing. Not all projects are
hosted on major sites, and having a (more complicated) way of tracking
versions based on a directory listing could be useful. I do not know
how to exactly implement that (maybe a regexp to match only the files
we want and a sed/awk script to do the $tarball -> $PV pass).
If I remember correctly debian has something like that for version
tracking, so it may be worth having a look.

Alexis.

[1] http://dante.ctan.org/tex-archive/help/Catalogue/catalogue.html
[2] http://texcatalogue.sarovar.org/

Upstream tags in metadata.xml (GLEP 46)
 

В Чтв, 04/02/2010 в 22:37 +0100, Tiziano Müller пишет:
> The upstream tags are meant as a way to track information about
> - id of a hosting or indexing site (automated version bump checks)

Does there exist any scripts for this?

--
Peter.

Upstream tags in metadata.xml (GLEP 46)
 

Am Freitag, den 05.02.2010, 20:16 +0300 schrieb Peter Volkov:
> В Чтв, 04/02/2010 в 22:37 +0100, Tiziano Müller пишет:
> > The upstream tags are meant as a way to track information about
> > - id of a hosting or indexing site (automated version bump checks)
>
> Does there exist any scripts for this?
>
Not that I know of. I once started working on one.

--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

Upstream tags in metadata.xml (GLEP 46)
 

Am Freitag, den 05.02.2010, 11:34 +0100 schrieb Alexis Ballier:
> > Other sites I'd like to add:
> > - pypi
> > - google-code
> > - ctan ... if someone can identify a key for packages
>
> I don't know what you exactly mean by a key, but for ctan the
> catalogue [1,2] may be what you're looking for.
> If I understood correctly, a key would be $PN and the relevant
> information found in, e.g.,
> http://texcatalogue.sarovar.org/entries/${PN}.html
>
> Note that not all packages have version information; if they don't, one
> can probably use the date instead.
Last time I checked I didn't have the impression that ${PN} is not
enough to get a unique entry for a package on ctan.

>
> If I remember correctly, texlive has perl scripts/libs to deal with it,
> so it may be possible to reuse them for a bumpchecker.
>
> Also, definitely +1 for adding more sites, but I think one important
> feature is missing: simple http/ftp listing. Not all projects are
> hosted on major sites, and having a (more complicated) way of tracking
> versions based on a directory listing could be useful.
Definitely, but for http/ftp listing checks SRC_URI is probably enough.
The only thing which could make it easier is when upstream uses
sub-directories for major/minor versions (like gnome for example). In
that case something like <remote-id
type="ftp">http://ftp.gnome.org/pub/GNOME/sources/GConf</remote-id>
might help to find a new version easier, but I really doubt it.

But for now I'd stick to the two cases:
a) hosting sites with project numbers/ids/names where we can extract
version information in a general way
b) arbitrary download sites, in which case a bump checker could try to
find new versions by checking for a http/ftp listing or by checking the
Changelog (<changelog>...</changelog>) which may also be a good way to
know whether something changed at upstream (and then let the developer
decide what it was)

> I do not know
> how to exactly implement that (maybe a regexp to match only the files
> we want and a sed/awk script to do the $tarball -> $PV pass).
> If I remember correctly debian has something like that for version
> tracking, so it may be worth having a look.
>
> Alexis.
>
> [1] http://dante.ctan.org/tex-archive/help/Catalogue/catalogue.html
> [2] http://texcatalogue.sarovar.org/



--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

Upstream tags in metadata.xml (GLEP 46)
 

On Thu, Feb 4, 2010 at 7:05 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday 04 February 2010 16:37:01 Tiziano Müller wrote:
>> While some people already discovered the upstream metadata tags, there
>> are only 8 ebuilds using them so far. Mostly I am to blame for that,
>> since I forgot to send out a proper announcement. While all the required
>> information can be found in the Developer Handbook [1], here is a short
>> summary:
>
> anyone who feels like doing this kind of work should feel free to add any
> <upstream> tags to base-system/toolchain/games packages ... no need for
> bugzilla and such.
> -mike
>

Ditto on base-system/mythtv/app-emulation

--
Doug Goldstein