[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status bibref gatherer (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)

Le Thu, Mar 29, 2012 at 04:02:18PM +0200, Andreas Tille a écrit :
> On Wed, Mar 28, 2012 at 03:55:42PM +0900, Charles Plessy wrote:
> > The names in packages-metadata should be source package names, and I have
> > improperly used binary package names when parsing the blends task files.
> > 
> > One more item to add the TODO list...
> I found another instance (besides probably several R packages):  The
> binary package has bibliographic information but the source is named
> ball.  Do you consider the switch from binary packages to source
> packages a hard to do change?  Do you want me to have a look (if yes,
> some hints might be helpful).

Hi Andreas,

it should be easy: what is needed is a safeguard.  For existing packages,
umegaya uses debcheckout to guess the URL, and debcheckout kindly works with
source and binary package names.  Before calling debcheckout, there should
be a mechanism to trigger an error if the query is not a source package.

$ debcheckout -d qtl
type	svn
url	svn://svn.debian.org/debian-med/trunk/packages/R/r-cran-qtl/trunk/

$ debcheckout -d r-cran-qtl
type	svn
url	svn://svn.debian.org/debian-med/trunk/packages/R/r-cran-qtl/trunk/

For packages not yet in the debian archive, there is another URL guesser, which
has the same problem.
> Would it somehow be feasible to trigger a "complete reimport of
> debian-med repository" because I did several changes to make the move
> to the information in the upstream files as smooth as possible.

I will trigger a mass reload tomorrow morning, but will not have time to
implement the safeguard before.  As a temporary workaround, a small script that
beeps when it detects a wrong package name in the pool would be as useful.

I am unexpectedly busier and busier this week, so I may not be able to do
much apart from the reloads.


Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan

Reply to: