Hi Yaroslav, On Thu, Jan 03, 2013 at 10:32:50AM -0500, Yaroslav Halchenko wrote: > ... > > So duplicating DebTags (or even inventing competing tags) should > > be really be prevented. > > I do not see any reason in competing with the > > DebTags system inside debian/upstream files. It might be debatable > > as well whether these tags qualify as "upstream" information. > > yeah -- I feel unease here as well in regards of possible duplication of > debtags. Placing aside possible debate on either stating the field:: is > "upstream" information (imho it is) -- let's check with debtags > master (CCed) first about possible expansion of available debtags: > > Enrico -- IIRC there was some discussion long ago with some conclusion > of having a somewhat restricted set of debtags defined, e.g. we > have atm:
I replaced Enrico's private address by DebTag devel list where it IMHO belongs to. > $> grep field:: /var/lib/debtags/vocabulary > Tag: field::TODO > Tag: field::arts > Tag: field::astronomy > Tag: field::aviation > Tag: field::biology > Tag: field::biology:bioinformatics > Tag: field::biology:molecular > Tag: field::biology:structural > Tag: field::chemistry > Tag: field::electronics > Tag: field::finance > Tag: field::genealogy > Tag: field::geography > Tag: field::geology > Tag: field::linguistics > Tag: field::mathematics > Tag: field::medicine > Tag: field::medicine:imaging > Tag: field::meteorology > Tag: field::physics > Tag: field::religion > Tag: field::statistics > > field:: tags overlap greatly with current split of packages into tasks > in Debian blends (e.g. see http://debian-med.alioth.debian.org/tasks). > I wonder -- how rigid the set of field:: tags and specifically, > subfields (e.g. ::medicine:imaging above) is? would you accept an > expansion of the list sufficient to better cover existing (sub)fields of > science/medicine/etc? > > Thank you in advance > > > > e.g. shouldn't all packages tagged with field::medicine:imaging be > > > a part of debian-med imaging ? ;-) > > Yes. Currently there is no way to syncronise DebTags with tasks. This > > on my todo list since a long time and it never made it to the top of it. > > Why not simply adding missing packages to the task if you are aware > > about such packages? > > because > - seeking more of automation (debtag there, add to blend X task Y, > add to blend Z task W, ...). And if we ever come up with > neurodebian blend -- we would be doomed to traverse the lists again? > brrr > - that is why I crafted ad-hoc blends-inject script originally to inject > into multiple tasks (need for it is now partially obliterated by > parsing debian/upstream from perspective packages repositorieS) > - and that is why I initiated this tread in a hope to deprecate need for > blends-inject completely ;-) I'd be more than happy if we could find a way to sync DebTags and tasks more closely but I admit I do not even have a slight idea how to reasonably do this at the moment and I'm a bit swamped by a lot of good ideas (the interface I promised to Michael for the tasks pages content to enable creating the known NeuroDebian pages is right on top of it) so I simply did not touched those things I do not have neither time nor a clue how to reasonable do it. If you come up with a clever idea I'm all for doing some reasonable stuff. BTW, I can not really believe that for the moment adding some (probably less than 10) lines of "Depends: <binarypackage>" to the relevant task is such a lot of work. As I repeated several times all other information is drained either from package pool or from Vcs if not yet uploaded - so there is really not much work and finally the tasks pages could be a helpful visualisation to design reasonable DebTags. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
