Re: Merge debian/blends into debian/upstream? [Was: Additional fields in debian/upstream?]
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
Reply to: