hardware:: tag matching lib plans

Enrico Zini enrico at enricozini.org
Fri Jan 20 11:43:43 UTC 2012

On Mon, Jan 16, 2012 at 04:39:52PM +0100, Michael Vogt wrote:

> > I like the idea. In fact, the whole hardware::* tag could be managed by
> > the maintainers of the detection library, effectively as part of that
> > project. The two things will give each other meaning.
> Cool idea! The project is still in the infant stage but some stuff
> appears to be working already. My initial goal would be to cover the
> current tags plus additional meaning like "requires writer" that are
> combinations of tags (like you outlined below).

Would you like to add the code to the debtags package[1]?

I've recently started to add python scripts to it (see
debtags-submit-patch and debtags-fetch), and this whole thing calls for
a "debtags-hardware" script that would output the hardware detection

[1] ssh://git.debian.org/git/debtags/debtags.git

> > > Tag: hardware::storage:cd:writer
> > > Description: Compact Disc writer
> > > (or hardware::storage:cd-writer ?)
> > > 
> > > Tag: hardware::storage:dvd:writer
> > > Description: Digital Versatile Disc writer
> > 
> > This is something that I would prefer to get via a combination of
> > different tags: use::viewing/use::editing, for example, to distinguish
> > between cd/dvd players and cd/dvd writers. If that strategy gives
> > wrong results, then we can consider adding special tags.
> Nice! Yeah, I can certainly change the code in the lib to look at the
> use:: tag and check for CD/CD-writer depending on it.

Cool. I reckon the results would need to output both positive and
negative matches. Something like:

 ok: hardware::storage:dvd, use::viewing
   + found DVD reader "Pioneextor Fasturbo 42x" at /dev/scd0
 no: hardware::storage:dvd, use::editing

I think you need both to be able to give proper hints, otherwise the
hinter wouldn't know if a hardware tag combination isn't supported by
the system, or of instead it's just a combination that the checker
doesn't check for.

> > Things could be fixed by putting tags in debian/control, at some point.
> > It could be time to reevaluate that option, but even if we started
> > working on that now, I don't think it's going to happen before at least
> > 6 months.
> Thanks! I'm not very concerned about it at this point but its good to
> keep it in mind. As a workaround we still could add XB-Tag to the
> debian/control file, couldn't we? Or will that cause other problems?

We could, I'm starting to think of a strategy for that that would also
address the requirement I have from maintainers to be able to say "I'd
like to declare these tags of my packages as 'stable'".

I'll think a bit more about it, then send out a proper proposal.

> > The other issue I see is that the logic isn't very extensible: if
> > tomorrow you need to track another hardware feature that requires a <=
> > or >= comparison and not just an 'has tag' one, then you're stuck. OTOH,
> > if such needs arise, then it's time to design a specially crafted
> > control file header, but at least tags took us to that point.
> Thanks again! I would prefer not to use special headers as we have
> enough of them already and debtags feels to me like a much nicer and
> more general solution.
> I'm not quite sure I understand the limitation here correctly. At
> least for the memory case it could work like this:
>  Ceck if HW requirements are meet by building up a search that
>  include hardware::memory:1GB if the machine has at least 1GB
>  memory. When checking the requirements it would iterate the tags and
>  simply parse the value when it finds "hardware::memory:" and compare
>  it. For a query it could add some tags based on the HW  (at startup
>  or when building the query) or possible using a xapian KeyMaker
>  (probably not very fast when python is used though). Not very
>  granular, as it would probably just {0.5,1,2,4} GB initially and a
>  machine with 4g would simply include a or-query with all of those values. 
> Or would that be considered ugly? 

Alternatively, with negative hints, packages can have tags like:

  hardware::memory:2GB  # 2GB or more
  hardware::memory:4GB  # 4GB or more
  hardware::memory:8GB  # 8GB or more

for which the hardware detection code can produce negative matches:

  ok: hardware::memory:2GB+
    + found 2GB RAM, 1GB swap
  no: hardware::memory:4GB+
  no: hardware::memory:8GB+

> > More ideas for hardware tags can come from looking at:
> > http://debtags.debian.net/edit/tags/hardware::TODO
> > (I'm sorry it it still misses a 'next page' option)
> Very nice, thanks! Looks like bluetooth and wifi are obvious
> candidates from looking over the list (and maybe firewire 1394 but I
> don't know much about that myself).

Bluetooth was easy: added:

 Tag: hardware::bluetooth
 Description: Bluetooth

Wrt wifi, I don't know the technology well enough: should we just do
hardware::wifi, or is there already a need to distinguish a, b, g, n or
whatever thing they'll come out with this year?

My gut feeling would be to avoid going into that kind of detail, but
maybe for practical purposes it makes strong sense to do it and I just
am not aware of it.



GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20120120/dbc74a3e/attachment.pgp>

More information about the Debtags-devel mailing list