On Wed, Apr 11, 2018 at 10:02:39PM +0200, Ole Streicher wrote: > > From your experience: do you think there are chances to get an > additional table with normalized dependencies?
Just ask for commit permissions. I have created several tables and wrote the according importer. As long as you do not touch existing tables and also not break any importer that should not be any issue. I have `sudo udd` permissions on udd.debian.org and can bring your code into production. > Queries like for reverse dependencies or reverse suggestions seem quite > normal to me. Especially when it is called "Ultimate" :-) ACK. > > Yes. Didn't I told you that server side queries tend to be complex? > > > > The good thing about PostgreSQL is that it has really nice features. > > I'm using arrays to solve this. To get the authoritative answer you > > were seeking above just do: > > I would probably prefer to use a (temporary) view here, since it could > then work as if the database was normalized. There are always different solutions. > But I have to learn more > Postgresql first... And the performance problem persists ofcourse. As I said: Regarding queries for some static applications performance is OK. When using blends-dev I personally do not mind if it takes 1 or 5 minutes (may be 15min would be a bit boring admittedly). > > PS: The main reason to use UDD was the "Architecture: any" feature. As > > far as I can see that's not implemented yet and left for a future > > release. That's perfectly fine since the current implementation is even > > now better than the old Perl script. I just want to make sure that I > > have tested all new features. > > We had a short discussion in > > https://lists.debian.org/debian-blends/2018/03/msg00059.html > > and your answer. Do you mean something more? I mean we need different metapackages for say amd64, arm64, i386, etc. I agree that this is no solution for MultiArch but from my point of view that's rather a corner case. However, our metapackages are currently simply broken for all architectures except amd64 and I'd love to get this fixed in Buster. As I said blends-gsoc had some solution for this: BTW, I was just running `make dist` with blends-dev from gsoc installed. Here is a snippet of git diff --ignore-all-space debian/control ... Package: med-bio -Section: metapackages -Architecture: all -Depends: ${misc:Depends}, - med-config (= ${source:Version}), - med-tasks (= ${source:Version}) +Architecture: any +Priority: extra +Depends: med-tasks (= ${binary:Version}), med-config (= ${binary:Version}) Recommends: abacas, - abyss, - acedb-other, - adapterremoval, - adun-core, - aegean, - aevol, + abyss [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386], + acedb-other [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386], + adapterremoval [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386], + adun-core [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386], + aegean [!s390 !hurd-i386 !mips64el !kfreebsd-amd64 !powerpc !sparc !ia64 !mips !kfreebsd-i386], + aevol [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 !kfreebsd-i386], alien-hunter, ... I wish we would head for something like this. It has another really great feature. It has the following warning output: WARNING:__main__:"filo" has been replaced with "bedtools" WARNING:__main__:"libodil0-dev" has been replaced with "libodil-dev" WARNING:__main__: **Missing package python3-bd2k has the following existing versions: WARNING:__main__:python-bd2k WARNING:__main__: **Missing package libodil0-dev has the following existing versions: WARNING:__main__:libodil-dev This would be some nice remaining TODO item - specifically since it has for instance a hint to the libodil0-dev issue. So it makes definitely sense to have a deeper look into that code. > P.S. please excuse the harsh tone of my last mail, that was not really > intended. I did not received it harsh. :-) I consider it factual and as I said I can perfectly feel with you since I was in the same situation some years ago. I just tried to explain the motivation of the initial design decision which has definitely limitations for these days applications. Kind regards Andreas. -- http://fam-tille.de
