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

Hello Andreas

On Thu, Jul 4, 2013 at 1:17 PM, Andreas Tille <andreas@an3as.eu> wrote:

The whole argumentation is based on the argument that some the very same
alternatives are used in every task of any blend in the same way. But
there is absolutely no reason to assume this.

Yes I know, that's why as primary keys of the blends_dependencies_alternatives are the blend field and the task field. So each time we will check for alternative packages inside a list of dependencies we are going to check for a specific blend-task(and dependency field) pair.

You can habe

blendA_taskX:
Depends: pkg1, pkg2 | pkg3

So this alternative relation : pkg1, pkg2 | pkg3 will only be used for the blendA taskX for the "d"(Depends) list of packages

blendB_taskY:
Depends: blendB and taskY pkg1 | pkg2
Suggests: pkg3

This will used only for blendB and taskY and so on

In order to group the packages from the blends_dependencies table we use the blend,task,dependency fields and we get a result set as:

For "blend" : "debian-med" :

{ ...

"task" : "bio" ,

"Depends" : [ "package1", "package2"... ],

"Suggests" : [ "package3", "package4"... ]

.... (etc)

}

We will use the same fields to also group the packages from blends_dependencies_alternatives : blend-task-dependency.That way we won't have to worry about similar alternatives into different tasks because we are going to check each time only for a specific blend-task. Anyway I will think it over again to think of any other possible problems.

I do not know a real existing example but I guess you could find one.
Hmmm, checking:

udd=# SELECT alternatives from blends_dependencies_alternatives where alternatives like '%k3b%' or alternatives like '%brasero%';
alternatives
--------------------
k3b | brasero
k3b-i18n | brasero
k3b
brasero

So if you find brasero or k3b what would you enter into the resulting
task file?

Can you also print out the blend and the task field of this? Also I have one question: why does this table contain the k3b and brasero packages as standalones? what I mean is that the blends_dependencies_alternatives in the alternatives field should only have strings into this format "package1 | package2" so strings which contain the logical OR "|" inside them.

Well, that is just *our* alternatives string but not the one the editor
of the tasks file has injected. What of he did it on purpose in a
different way?

I can not think of an example, what do you mean by different way? Is there a possibility instead of returning the packages(lets say the alternatives) in a different way than they are in the task files?

Yesterday I made some additional progress but it seems I have some
remaining error, because I get more lines in the alternatives table
than in the pure package dependencies table:

udd=# SELECT (SELECT count(*) from blends_dependencies_alternatives) as altcount, (SELECT count(*) from blends_dependencies) as depcount ;
altcount | depcount
----------+----------
5764 | 5022

I'd like to check why this is the case to this extend before I commit
this to the public Git repository.

This is probably happening because the importer might include all the packages into the blends_dependencies_alternatives along with the alternatives into the format "package1 | package2". Like the results you got above:

alternatives

--------------------
k3b | brasero
k3b-i18n | brasero
k3b
brasero

This should only contain the k3b | brasero and the k3b-i18n | brasero (and not the "single" packages: k3b, brasero)

So the reason you get more lines in the alternatives table is (maybe) because the 5022 single package dependencies from blends_dependencies table are also added in the blends_dependencies_alternatives and you also add the strings which contain "|" so the raw strings "package1 | package2" which maybe are 742 (5764- 5022). So the blends_dependencies_alternatives should not contain single packages only boolean "|" package strings

> > Meanwhile I'd recommend you might look into the source of the openjdk7
> > package how the different control files for the different architectures
> > are created there. Perhaps this might give you an idea because it seems
> > even after my rewording on debian-mentors there was no helpful answer to
> > your question.
> >

I looked into the openjdk source package. In a previous discussion we had you mentioned that the same package(openjdk-7-jre) has different description for different architectures, that's true. They do have multiple control files and most of the attributes inside the different control files have as values variables taken from the makefile rules. For example in the description field of the openjdk-7-jre they have Description: OpenJDK Java runtime, using ${vm:Name} where the vm:Name is defined using the architecture of the host where the package is build.

They actually "fill in" a lot of parts of the control file from the rules file which is using info(mostly the architecture) of the host where the package is build. Quoting your words from your mail in the debian-mentors list

- - - -

I could imagine some kind of debian/control dummy file that will be
saved and replaced in the build target and restored in the clean target.
Seems to be doable but somehow hackish.

-----

In openjdk they do it more or less the same way as you say above, so I think if we can also do it that way :-)

Greetings from Porto Alegre (I'll now have breakfast ;-))

Wow I just realize the time difference we have :-). Also greeting and have a nice day :-)

Kind regards

Emmanouil