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 -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127023542.gc27...@falafel.plessy.net