Re: New feature for 0.6.103
Hi Ole,
On Wed, Apr 11, 2018 at 01:25:12PM +0200, Ole Streicher wrote:
> Andreas Tille <andreas@an3as.eu> writes:
> > BTW, what do you think about the usage of blends_dependencies instead
> > of creating a set of packages by other means?
>
> Seems useful for the web pages, but not for blends-dev: to generate the
> list of packages for a specific blend, the current (maybe uncommitted)
> tasks should be used, not the ones that are provided by the database.
OK, fine for me.
Regarding the test I did with latest HEAD of blends-dev.
It seems the usage of GENCONTROL_OPTS in Makefile does not work yet. I
did
$ git diff Makefile
diff --git a/Makefile b/Makefile
index e05adcc..e5ae206 100755
--- a/Makefile
+++ b/Makefile
@@ -2,6 +2,8 @@
BLENDMAKEFILE=/usr/share/blends-dev/Makefile
+GENCONTROL_OPTS = --udd
+
CheckBLENDMakefile := $(shell if [ -e $(BLENDMAKEFILE) ] ; then echo 1 ; else echo 0 ; fi)
ifeq ($(CheckBLENDMakefile),1)
include $(BLENDMAKEFILE)
which resulted in
/usr/share/blends-dev/blend-gen-control -r "unstable" -S -t
/usr/share/blends-dev/blend-gen-control -r "unstable" -S -c -m
Can you check the usage of the variable again. I've seen your according
commit but may be that the Makefile variable does not make it into the
environment of the Python script?
After doing manual
/usr/share/blends-dev/blend-gen-control --udd -r "unstable" -S -c -m
I get a single diff:
diff --git a/debian/control b/debian/control
index 781776a..bd0bea7 100644
--- a/debian/control
+++ b/debian/control
@@ -1402,7 +1402,6 @@ Recommends: cimg-dev,
libmiaviewit-dev,
libminc-dev,
libnifti-dev,
- libodil0-dev,
libopenigtlink-dev,
libopenslide-dev,
libopensurgsim-dev,
@@ -1444,6 +1443,7 @@ Suggests: emokit,
liblimereg-dev,
libmni-perllib-perl,
libnifti-doc,
+ libodil0-dev,
libopenmeeg-dev,
libopenslide-java,
libvia-dev,
That's way better than yesterday. ;-) While that's just a mistake in
the tasks file (it should rather read libodil-dev!) I'll leave it for
debugging purpose for the moment. It seems the UDD query does not
handle "Provides" correctly. I think the issue is the following:
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)
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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: