Re: New feature for 0.6.103
Hallo Andreas,
Andreas Tille <andreas@an3as.eu> 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
Reply to: