Hallo Andreas, Andreas Tille <[email protected]> writes: > It seems the usage of GENCONTROL_OPTS in Makefile does not work yet. I > did [...]
> +GENCONTROL_OPTS = --udd IMO there is an export missing. Otherwise GENCONTROL_OPTS is only local. You could try $ GENCONTROL_OPTS="--udd" /usr/share/blends-dev/blend-gen-control -r "unstable" -S -t to check whether it retrieves from UDD then; for me it works. > SELECT packages.package, packages.provides, packages.architecture, > packages.version FROM packages WHERE packages.provides like 'libodil%' ; > > is just empty, but you get: > > udd=# SELECT DISTINCT packages.package, packages.provides, packages.version > FROM packages WHERE packages.provides like '%libodil%' ; > package | provides | version > --------------+-------------------------------+--------- > libodil0-dev | libdcmtkpp-dev, libodil-dev | 0.7.3-1 > libodil-dev | libdcmtkpp-dev, libodil0-dev | 0.8.0-4 > libodil-dev | libdcmtkpp-dev, libodil0-dev | 0.9.1-1 > libodil-doc | libdcmtkpp0-doc, libodil0-doc | 0.8.0-4 > libodil-doc | libdcmtkpp0-doc, libodil0-doc | 0.9.1-1 > (5 Zeilen) > > This means you can not expect an exact match on the package name since > provides can have a list of packages (which again proves my point that > UDD queries become always more complex than expected. :-P) Huh! That is ugly! Who made this??? At least this contradicts to everything I learned about databases: if there may be more than one provides for a package, there should be an extra table for this relation. Same for other dependencies (depends, recommends etc.). How does one query for "give me all packages that provide (or depend on) xyz"? With "like", you basically need to retrieve and parse all "provides" fields that are in the database with no chance to index it... and this has to be done for all O(1000) packages of Debian Science. Sounds really slow, especially when you want to get an authorative answer (your example would also find f.e. a package calibodil-dev, if that would exist). IMO the clean solution would be to have a "package-dependencies" table with the columns package, type, dependencies (or one table for each dependency type), if that does not exist yet (I must admit that I may have not searched carefully enough yet). But solving this on client side sounds like an ugly hack to me. Or do I miss something here? > Unfortunately I need to finish now an will not be back on my keyboard > in the next 5 hours - otherwise I'd provide a patch for your query. Best regards Ole
