Re: Debtags for defining the minimal age that a program can generally be used
Hi Miriam,
On Thu, Sep 12, 2013 at 06:54:58PM +0200, Miriam Ruiz wrote:
> > Your vision is fine and I definitely share it. However, I fail to see
> > the contradiction. The tasks can perfectly be used for classification
> > as well. So if you want to invent new tasks
> >
> > age-0-3
> > age-3-6
> > age-6-xy
> > ...
> >
>
> Okay, that makes sense :)
>
> Is there any way to do it so that, at some point in the future we may have
> orthogonal classifications, like for example
> {0-3,3-6,6-12}x{educational,game,toy,development,office} ?
Hmmm, every task is totally independent. So the answer is probably no.
While you could for sure create tasks like this
educational-age-0-3
educational-age-3-6
educational-age-6-12
game-age-0-3
game-age-3-6
game-age-6-12
toy-age-0-3
toy-age-3-6
toy-age-6-12
...
and than create metapackages like
age-0-3:
Depends: educational-age-0-3, game-age-0-3, toy-age-0-3, ...
age-3-6:
Depends: educational-age-3-6, game-age-3-6, toy-age-3-6, ...
...
and
educational:
Depends: educational-age-0-3, educational-age-3-6, educational-age-6-12
...
I would consider this pure overkill. We intended to keep things simple
and so this should not be a proposal for a solution. Just to explain
chances and limits of the tasks approach.
> > just do so. The header of such a tasks file would be
> >
> >
> > Task: Packages fit for <agegroup>
> > Metapackage: false
> > # Comment: Metapackage false prevents creation of an according metapackage
> > # and just creates the web sentinel pages for your view and
> > # design polishing
> > Description: Debian Jr (Kids?) packages for <agegroup>
> > The following packages are targeting at <agegroup> according to the
> > upstream authors ...
> >
> > Depends: <pkg>
> > Remark: This <pkg> fits into <agegroup> because ...
> > # Comment: Remarks are printed below the package description in web
> > sentinel
> >
> > ...
>
>
> I'll try to do that for a initial set of data, and see how it goes. I'm a
> bit concern about the scalability of the design, if at some point we get to
> classify a big amount of packages that might fit into these categories
> (say, we finf 100 or 200 packages suitable for 6-9, or 9-12, or something
> like that).
... even if we might find this amount - I can not see in how far a Wiki
would scale better in this case. Yes, there is no scalablility problem
with DebTags but as I said, DebTags is an interesting technique we
should use but it is orthogonal to the design of tasks (and it could
take a long time until you have set 200 DebTags propagated to your
system in use).
> > The Blends concept is all about metadata. You can even access the Blends
> > metadata in UDD.
>
> Cool :)
If you like to play around a bit with this, here are some example
scripts I'm using as playground for development tools:
http://anonscm.debian.org/gitweb/?p=blends/website.git;a=tree;f=misc/sql
For a very simple example which I'm currently doing for some QA work: I
was wondering what package in our interest was not uploaded since a very
long time and might need some love. This is solved by
$ 0-aging.sh debian-junior
source | version | date | distribution
-------------------+---------------------+------------------------+--------------
xblast-tnt-levels | 20050106-2 | 2007-08-21 19:17:09+02 | unstable
xblast-tnt-musics | 20050106-2 | 2007-08-21 19:17:12+02 | unstable
xblast-tnt-sounds | 20040429-2 | 2007-08-21 19:17:13+02 | unstable
cdtool | 2.1.8-release-2 | 2009-11-04 02:13:20+01 | unstable
xaos | 3.5+ds1-1 | 2010-04-16 14:50:29+02 | unstable
extremetuxracer | 0.5beta-2 | 2010-07-20 15:09:42+02 | experimental
kdeedu | 4:4.4.5-2 | 2010-09-13 19:03:21+02 | unstable
gvrng | 4.4-1 | 2011-02-25 11:02:10+01 | unstable
xpilot-ng | 1:4.7.3-1.4 | 2011-11-25 11:49:08+01 | sid
freecol | 0.10.5+dfsg-1 | 2012-03-06 00:33:56+01 | unstable
...
which seems as if somebody shuold have a look into xblast ...
You can do *a lot* of interesting things with these tools. If only my
spare time would be sufficient to implement all the cool ideas I have
since Blends data are in UDD.
> > As I said: The DebTags idea is fine in principle but a bit orthogonal
> > to the tasks design. It is a nice add on we could have. In addition to
> > that it has obviosly some friction from the idea to realisation. This
> > could be avoided and once you have your design (preferably via the
> > suggested tasks) you can take over this to DebTags easily.
>
> Yup, if the debtag guys don't wanna cooperate with us, we will have to
> export it to our own debtags package, although that would be a less than
> optimal solution.
I think the canoncal answer in Debian is rather "if they don't wanna
cooperate with us we should become part of them and strenghten their
team".
> > I personally would consider an additional SQL database as technical
> > overkill and you said yourself you want to KISS.
>
> My thoughts, exactly.
:-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: