Re: [gentoo-portage-dev] DB and binary dependency

[tvali]

2006/3/22, Patrick Lauer <patrick@g.o>:
>
> There are a few reasons why this won't work :-)
>
> First: What if I have assembler? python? perl?
> Your example is limited to the C preprocessor.


Yes that i did tell there that it's limited to c already :) but bin dep,
after all, is limited to lib dependencies and probably just .so files --
which means probably not python (as it's too dynamic to programmatically
understand, where and which libs are used), not perl (as it doesnt have
binaries). So i dont see my version being much worse than bin.

If you have an assembler, then everything depends on which one you have. If
that's internal assembler of c, everything works fine ;) If that is some
macro-assembler, then there is a bit different syntax from c, but other code
is basically the same (parsing needed information out from assembler code is
not too hard).

If that's python, then you cant anymore make it so simple -- there is
nothing like #define in python, as it's dynamic. In python, you have several
ways -- adding dependencies in classical way; adding a *.c file, which talks
about dependancies or making some python script, which is able to tell on
what it depends -- the last way has the same weakness with bin dep that it
should be downloaded before.

About perl, i dont know enough to tell, how it could be used there, but
anyway, as it is scripting language, i think that smth similar to py
applies.

I think that there could be simple dependency builder for packages, which
will be compiled, but not for dynamic languages. There is no simple way in
dynamic languages for knowing, which libs will be used, even if you know the
useflags or have them "built" into pyc files. As code deps are only my
thought about repairing the biggest bottleneck in bin-dep - that you cant
say anything about deps of a random combination of flags without rebuilding
with excactly that combination -, i am not trying to make it usable in
dynamic/scripting languages.

Second: You'll have to get this depend information applied by upstream
> unless you want to patch every file ... and as upstream I'd laugh at
> anyone proposing that


This is actually simple build. I just told about method, which would allow
you to include dependancy metadata directly in c code. It could be
"compiled" into current portage dependancy data as well.

Third: Since there is no easy way of generating this automatically
> you'll have to replicate every bit of dependency information that is in
> the ebuilds. That will be much work, you won't keep ebuilds synchronized
> to the included dep info ...


Data in ebuilds should be generated from that data.

So in short, interesting concept, but I don't see how it can work and
> how it is an improvement over what we have now. Please don't reinvent
> the wheel ;-)


Yes, if it comes to wheels, i better try to invent a better wheel, not
reinvent an old wheel ;)

PS. in my last example, i dont show how useflags are related to #defines.
That's because i guess that it must be already described somewhere and have
not to be in c code :) I hope it is so ;)

Patrick
> --
> Stand still, and let the rest of the universe move
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
>
> iD8DBQBEIZTiqER3hOUoZM4RAkEtAJ913WnthMPjRZrUGQCgYnOw9Xcu7ACeO1Dh
> VKWKYb6XcDuugBJSSBFMgc0=
> =xD2e
> -----END PGP SIGNATURE-----
>
>
>


--
tvali

>From a programmer's point of view, the user is a peripheral that types when
you issue a read request.  -P. Williams

If you think your management doesn't know what it's doing or that your
organisation turns out low-quality software crap that embarrasses you, then
leave.  -Ed Yourdon

We all agree on the necessity of compromise. We just can't agree on when
it's necessary to compromise. -Larry Wall

[ http://www.softwarequotes.com/ ] -
http://www.softwarequotes.com/ShowQuotes.asp?ID=544&Name=Borenstein,_Nathaniel_S.
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry