Hello Andreas,
On Thu, Jul 4, 2013 at 8:07 PM, Andreas Tille <[email protected]> wrote: > > 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. > > :-) that's perfectly fine, I will do it both ways and then we can decide how it will be in final stage. > 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. > > Ok now it became perfectly clear :-), having this table, as I said above, I can do it both ways. > 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. > > Ok, thanks I didn't have in mind the "fun" Blend. > > > 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). > > Ok knowing this, also made things more clear. > > > 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. ;-) > > > First talk provided. ;-) > > ;-) Tomorrow I will try to finish at least one way(yours or mine) using the new table. For sure the weekend I will cover up the lost day(yesterday that I didn't work) and I will finish up both ways. Thanks for your fast feedback :-) Kind regards Emmanouil
