[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

Hi Emmanouil,

On Wed, Jun 26, 2013 at 11:54:36PM +0300, Emmanouil Kiagias wrote:
> On Wed, Jun 26, 2013 at 11:08 PM, Andreas Tille <andreas@an3as.eu> wrote:
> >
> > I called blend-gen-control but can not find any output.
> >
> > Did you provide the needed arguments?(if not my bad i forgot to mention).
> For instance it works like the current blend-gen-control. if you want to
> generate all the possible control files:
> ./blend-gen-control -b debian-med -c -D -S (so you have -c for gen_control
> -D for nodepends, -S suppressempty)

Ahhh - sure.  This is what we agreed upon.  I'd call it a useful feature
if either -c or -t would be a required option.  Otherwise it is
confusing if the script needs some time ... to do nothing.  But that's
cosmetics once you are used to it.  Finally the script is not intended
to be called manually.

> or for generating the task descriptions files you can do:
> ./blend-gen-control -b debian-med -t -S (-t for task_desc)

Seems the Key value is always med.  It should be like

Relevance: 10
Packages: list

Relevance: 10
Packages: list

But in the new output it is always only 'med'

> It you try it with the above arguments and you still don't get an output
> let me know.

It's fine now - I simply forgot about this behaviour of old blend-gen-control.

> > The idea to queery the packages table seems to be clever at first sight
> > but finally this is a "circular dependency".  Blend-gen-control is used
> > to create metapackages and these will be uploaded to Debian and from
> > there the information ends up in the packages table.  So on one hand you
> > have no chance to change these metadata nor do you get anything for new
> > packages.  So we need to find a different solution:  For the moment this
> > is very simple:  We just fix the values:
> >
> >    Priority: extra
> >    Section: misc
> >
> > The later is debatable but for the moment it would work.  Perhaps we
> > need to add a Section field directly into the tasks files to get better
> > control over this value (and move this metadate to the blends_metadata
> > table).  As far as I see it currently "Priority: extra" is the way to go
> > for metapackages.  This was discussed previously and we just can leave
> > it as is.
> >
> Oups i did not think about "circular dependency", but now it's clear. I
> will fix it.

Nonetheless - the more I'm thinking about we should discuss with other
Blends whether it makes sense to support an optional Section field
inside the tasks files which could be used to override the default of
"Section: misc".

> > I think we need to make sure that *every* information will propagate
> > into UDD.  If you are interested you can perfectly try to dive into
> > this.  It is
> >
> >     git://git.debian.org/git/collab-qa/udd.git
> >
> > and you need to redefine the table columns (see dir sql/) and adapt
> > udd/blends_metadata_gatherer.py to read in the data.
> >
> Yes I am interested, I will check that :-).

Feel free to send me patches in case you are unsure about changes to UDD.

> > You are perfectly right that this is a flaw inside the Blends table
> > structure.  The reason for this is that when I wrote this code I did not
> > hat the metapackage creation in mind but rather the pure set of packages
> > involved.  I have no really good suggestion whet to do here.  I'll try to
> > think about this - suggestions welcome.
> Ok, I will think about it better tomorrow and I will try to come up with an
> idea.

I guess it even goes into the direction of an additional table.  I do not
see a good way to squeeze the packages that are interesting for a Blend and
the alternatives inbetween these packages into one table.

> > You probably mean debian-mentors and yes, I'm reading this list.  Let's
> > wait for another 24h and lets see if wee need to find another wording.
> Ok, so we wait for this part.
> > As said above: I can not see any output in control/ of taskdesc/.  Any
> > idea what might be wrong?
> As I write in the beginning, try the script with the arguments. To get the
> list of the available arguments you can do:
>  ./blend-gen-control --help

You really want me to read the docs??? ;-)

> Note: Also check that if you add -c(which goes for gen_control ) and then
> you also add -t(which goes for task description files) it will only take
> the -c argument. Just like the current blend-gen-control it has a
> if-elseif-elseif into these arguments so it can not do them both the same
> time, it will either generate the control files or the task descriptions,
> not both (-c has the priority here)

OK, no reason to change this.

Kind regards



Reply to: