On Thu, 03 Jan 2013, Andreas Tille wrote: > > > > that describe the upstream work, as opposed to data related to the > > > > Debian > > > > archive or relationship with other packages. > > > +1 > > archive? what archive? ;-) other packages? -- there is none (only a > > loose connection to the Debian packages of this particular piece). > > But "the scope" is a good argument -- "blends"/"tasks" sound indeed too > > Debian-specific. But semantically -- shouldn't they be quite a good > > match to describe the domain/purpose of the software? > Well, basically my motivation for "+1"ing was that Blends is a Debian > internal thing which simply sounds wrong in a file called "upstream".
and I was nearly doing "+1" myself at first too since indeed "blends and tasks" are way too Debian-specific > > So may be we could converge on introducing tagging > > (similar/extending to debtagss)? Micahel has already confessed today > > committing an improved debian/upstream for fsl: > > http://anonscm.debian.org/gitweb/?p=pkg-exppsy/fsl.git;a=blob;f=debian/upstream;hb=HEAD#l29 > I'm strongly against duplicating information inside debian/upstream > files. I am myself against duplicating information in general ;) > 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: $> 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 ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
