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

Reply via email to