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. > 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). > 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. But then I still wonder about the "Acacia" example above! :) > > 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). cheers, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.