Merge debian/blends into debian/upstream? [Was: Additional fields in debian/upstream?]

[Andreas Tille]

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