Re: [DEP 12] Why chosing YAML.
Le Sat, Jan 26, 2013 at 02:24:32PM +0100, Guillem Jover a écrit :
>
> Although the more I think about it, given the context, the more I get
> the impression that this data might not belong in the package anyway,
> because most of the things it describes are more or less independent
> of the source package, and because having it somewhere else, where the
> maintenance could be shared with other distributions beside Debian
> would be really nice. The only drawback would be not having the
> information self-contained in the package itself, but there's
> precedent for that too, like debtags. But then it feels like I'm
> starting to repeat myself, so I think I'll leave this here.
Hi Guillem,
I started to work on debian/upstream with one design goal in mind: to be able
to update the information without uploading a source package. For this, we
(where we is intitially the Debian Med team) need a place where people can add
and modify information. Also, if we want to propagate this information without
much review, we need some access control. Lastly, we need the system to be
easy to use for the package maintainers, since we expect them to be the primary
suppliers of information about their packages.
The solution I found was to store the information in debian/upstream and
retrieve it from the VCS where the source package is stored. For the moment it
works well. From the blends.debian.net machine (currently down), using the
umegaya package, we are collecting up-to-date debian/upstream files in a pool
(which is made available to others through the collab-qa Subversion
repository), and then custom scripts digest this and feed the UDD. The UDD is
the primary distribution point of the contents of the debian/upstream files,
and the maintainers can update it trivially by commiting to their source
package's VCS.
http://wiki.debian.org/UpstreamMetadata
I completely agree that a cross-distro effort would be greater. But it is
completely beyond my skill, energy and free time to organise this. But if
something serious would emerge, I would be happy to throw away debian/upstream
to the bin (after feeding the information we already collected) and use this.
Altogether, I would like to keep the question of the information flow for
another DEP, and focus this one on the structure and syntax of the data...
more on this in another thread.
(And for debtags, I think that, while the current interface was instrumental
in bootstraping the system, I would manage my package's debtags better
if they were in the source package.)
Cheers,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: