Re: Non-normalised field Provides in UDD table
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 to: