Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)
On Thu, Jul 04, 2013 at 04:32:41PM +0300, Emmanouil Kiagias wrote:
> 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.
Ahh, that's a fair point I seemed to have missed. Probably you are
right here.
> > 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.
While beeing offline again (some talk rooms are not covered by WLAN) I
finally implemented my idea of the alternatives table which is now even
enhanced by distribution and component columns according to the fact
whather at least one alternative is in Debian main or contrib/non-free,
etc. I think this implementation does in no way conflict with your idea
and thus I'd suggest to keep this as long as we are not sure what way we
might go. My idea was to enable an alternatives table that can fully
replace the dependencies table and you might try some tests whether this
enables the same results as with your implementation where you only use
the "lookup alternatives" way. This experiment might lead to the right
solution, IMHO. The weak part in my approach remains that there is no
good way to find out whether the distribution / component information is
valid for a given architecture and this could be an advantage for your
approach. If this turns out to be the case we might strip the table
again some bit in a final stage.
> > 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?
I think I git your point but for completenes here is now all information:
udd=# SELECT * from blends_dependencies_alternatives where alternatives like '%k3b%' or alternatives like '%brasero%';
blend | task | alternatives | dependency | distribution | component
-------------+---------------+--------------------+------------+--------------+-----------
debian-edu | desktop-other | k3b | brasero | r | debian | main
debian-edu | desktop-other | k3b-i18n | brasero | r | debian | main
debian-ezgo | multimedia | k3b | d | debian | main
debian-ezgo | multimedia | brasero | d | debian | main
> 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, this was my idea from the beginning and I obviosly failed to
explain without implementing it - hope it becomes clear now. I went the
abstract route that even single packages are some "special case" of
alternatives. This is was I tried to say initially by "storing
verbosely all what you find between ',' signs" which might be single
packages or '|' separated sets of packages ("real" alternatives).
When thinking about it this approach might spoil your approach a bit -
but this could easily solved by a view showing only
SELECT blend, task, alternatives, dependency from blends_dependencies_alternatives where alternatives like '%|%' ;
which should exactly reproduce the content of your proposed table.
> > 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?
I think I was simply wrong here. Lets create the according control files
and check whether they reproduce the content of the tasks file. BTW, for
experimenting with side case you can always experiment with the "fun"
Blend - which exists just for debugging fun.
> > 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.
Problem solved.
> 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:
Well, the alternatives table should have "a lot" of entries but simply
not more than the dependency table. This is now fixed:
udd=# SELECT (SELECT count(*) from blends_dependencies_alternatives) as altcount, (SELECT count(*) from blends_dependencies) as depcount ;
altcount | depcount
----------+----------
4987 | 5080
> 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
The reason was actually that in the dependency table importer those packages
that are not inside UDD at all are simply thrown away. Obviosly there are
a lot of them - because after I implemented this for the alternatives I've
got the numbers as expected. Now some more reasonable number because the
"view" above has 69 entries where some have more than one element in the
alternatives string - so a difference of 93 makes perfectly sense (without
having checked the actual numbers).
> 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 :-)
So it seems at least in this respect I was not totally insane. ;-)
> > 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 :-)
First talk provided. ;-)
Kind regards
ANdreas.
--
http://fam-tille.de
Reply to: