Re: shall we keep collecting suggestions in the task files?
On Wed, Oct 22, 2014 at 03:21:32PM +0200, Holger Levsen wrote:
> Hi,
>
> On Mittwoch, 22. Oktober 2014, Andreas Tille wrote:
> > 1. Add some rudimentary packaging in your packaging VCS containing
> > a valid d/changelog, d/control including Homepage and description
> > and optionally a DEP5 formatted d/copyright skeleton. There is
> > an UDD importer that fetches this data and adds the info to the
> > tasks page.
>
> nope, that doesnt fit here.
>
> > 2. Add the metadata right into the tasks file.
> >
> > Both is explained in the Blends documentation[1]. Option 1. is prefered
> > since it shows that your interest into the package is somehow "honest".
> > The Med Bio task[2] provides an extensive example of all options.
>
> so the first software there is "Acacia" an "Error-corrector for pyrosequenced
> amplicon reads.", how is that in your task file? how is that even part of the
> debian-med source package?
>
> matrix:~/m$ apt-get source debian-med
> [...]
> matrix:~/m$ cd debian-med-1.13.2/
> matrix:~/m/debian-med-1.13.2$ ls
> AUTHORS config COPYING debian debian-med-tasks.desc Makefile menu
> README tasks tasks.ctl
> matrix:~/m/debian-med-1.13.2$ grep -i Acacia tasks/*
> matrix:~/m/debian-med-1.13.2$ rgrep -i Acacia *
>
> hmmm.
Try
debcheckout debian-med
instead. The tasks pages are created from VCS rather than the package
source.
> > I personally think that so called "prospective packages" should always
> > be accompanied by some metainformation which enables rendering on the
> > tasks pages. If you do not mind providing this bit of information I
> > doubt that the intent to work on this will be really honest.
>
> there is no(t neccessarily an) "intend to work on these packages", sometimes
> we just want to track them (and use them if someone else packages them).
You could at least add a Comment about this ...
> > So it is
> > really easy to detect "dust": Dependencies that are not in the Debian
> > package pool and do not have any metainformation are dust, IMHO.
>
> yeah, maybe. I've looked at
> http://blends.debian.org/blends/ch08.html#edittasksfiles now and "Ignore"
> seems to be what we want and which we already use for such packges.
The "Ignore" exists for this very purpose and was injected by Petter.
> But then I still wonder about the "Acacia" example above! :)
You simply need to understand that we try to get the information as
current as possible and the source packages are simply static. Any VCS
commit to the tasks files will trigger a rerendering of the tasks pages
(after 15min cron job).
> > > I've checked some of the packages and some of them are indeed provided by
> > > alternatives, so I don't think now is there right time to clean this up,
> > > but rather after the Jessie release.
> > Hmmm, unfortunately this argument was used even two releases before. :-(
>
> Unfortunatly it's again true.
:-(
> > No. Blends-dev has a feature to deal with non-existing packages.
>
> Great. Just that it doesn't seem to be enough / used / used correctly, for
> whatever reason(s).
... in Debian Edu. That's correct.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: