Hi everyone!

I'm starting this topic, because a question about dependencies of packages was raised in a package creation. You can find it here.

Here's the question:
If you have package A that depends on package B and package B depends on C, but the A.dep file lists only package B then a "netpkg A" command will parse B.dep and download C. Me and _PN_boy tested this and concluded that netpkg works like that. So my question is. Why still use flat dependencies in package creation?

Like gapan said:


I agree with him about the simplicity, but i think this policy will give many problems, because some times it's really difficult to check all dependencies for one package because they are many. Maybe requiredbuilder should in another way to get the dependencies. (eg. if requiredbuilder could get the dep A of a package and the deps of dep A, and so on, would be great. Working in a recursively way).

I'm raising the question because there are many packages that aren't following this policy. I would like to know more opinions about this.

Regards,

Hey,

I like the current system the way it is. Adding recursive dependencies into requiredbuilder would take more CPU time, and if netpkg already works recursively I see no need for it. There are not many recursive dependencies that I know of either. "If it ain't broke don't fix it." :-)

What does everyone else think though?

Just my thoughts,
sega01

Hi,



Sorry but i don't think the same way! Yes it ain't broke, but if we can do better why don't?

Regards,

i would go with what gapan said. that's some real advantage i think. but i can understand your point as well. perhaps you should have started this as poll.

I don't see so many advantage on that. And yes, the requiredbuilder will take more CPU time to retrieve all dependencies. But i think that time will be consumed for a good cause. Look, like it is now, there's much probability to had wrong dep files, because sometimes we have to add manually deps and when human do things the probability to have a flaw is much higher.

But if there are many people that like flat deps, i think is better to get an automatic way to generate the dep files.

Regards,

They are automatically generated via requiredbuilder currently. Some things might have to be added in manually in rare cases, but it's almost entirely automated. I agree that if it's not broken and can be improved, it should be improved - but how is slowing down requiredbuilder to get it to do something that netpkg does automatically improving it? I see no benefit to this.

Just my thoughts,
sega01

Hi,

The point that Dennis is referring is, example:
some package as a dep on kdelibs, requirebuilder will not put all the deps on kdelibs: "acl,alsa-lib,arts,attr,audiofile,avahi,bzip2,coreutils,cups,cxxlibs,dbus,esound,expat,fontconfig,freetype,gawk,gcc,glib2,gnutls,grep,krb5,libart_lgpl,libdrm,libgcrypt,libgpg-error,libidn,libjpeg,libmad,libogg,libpng,libtiff,libvorbis,libxml2,libxslt,mesa,pcre,perl,qt-base,sudo,xorg,zlib"



Regards,

A good example is python related packages like gconvert (in the repos). If requiredbuilder is run on them only python will be reported as a dependency but the .dep file I've made for gconvert lists all python deps:

libglade does not get picked up by requiredbuilder at all but it is absolutely needed so I also added it and its deps.

That's exactly why I believe it's a perfect example! 

Well, it's a mix of both I think. This discussion started in the rkward testing thread where rkward depends on php, but php's own dependencies were not picked up by requiredbuilder.

Now, should the packager:
(A) manually edit the .dep file to include all deps and go for the flat dependency model or
(B) leave it as it is having recursive dependencies and let netpkg do its thing? In the rkward example, only php gets in rkward.dep file and php's deps are calculated and downloaded with netpkg. In the gconvert example, only "python,libglade" are included in gconver.dep and netpkg installs their deps.

I'd go for (A) for the reason Dennis quoted me on in the 1st post - simplicity.

Well, (C) is really (A) hidden in ZENBUILD so...

I prefer (B), simply because it is more automatic. (A) is fine, but only if it is possible to perform that in an automatic way... (like netpkg does).
This is my humble opinion 

Cheers

and I'd choose D) make buildpkg handle this for us

Explain:
all packagers will most probably have this file in there systems: /var/netpkg/db/depfile(netpkg created file) this contains all the deps, perhaps buildpkg could do something like(algorithm):
parse the dep line of the package being build;
grep all those deps with something like: "grep -e "$dep1:" /var/netpkg/db/depfile and add those deps to a new dep line(also containing $dep1) the ":" are mandatory, so that it won't happend something like "grep -e "php" /var/netpkg/db/depfile that would report back php and phpmyadmin, per example;
add -u to the line "for deps in \$(echo "\${depstring}" | sed 's/,/\n/g' | sort); do" to stay like: "for deps in \$(echo "\${depstring}" | sed 's/,/\n/g' | sort -u); do" -u for unique, so that no deps are repeated

not tested, but pretty sure it will work

Regards,

(D) looks nice but it doesn't work when some of the dependencies are installed manually and not through netpkg.

Hi there, this is a nice idea. however, I would implement this in a separated script, so that even those who do not use buildpkg can use it in their buildscript. Moreover, the depfile created by netpkg is there after netpkg has downloaded info from the repo, I guess. What about dependencies of packages that are not in the repo yet? I think it can happen in the case of packages installed by the builder for the preparation of a given package. Am I wrong?

Cheers 

EDIT: sorry gapan, I hadn't read yet ;-)