On Friday 24 March 2006 15:24, tvali wrote:
Unfortunately, your wrong. This only makes sure that you have the
right slots to put your squares, triangles and circles in. It does
not say that b(int,int) from the first lib actually does the same
thing as b(int,int) from the second library.
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Thursday 23 March 2006 21:35, tvali wrote:
BINSLOT is a new word for me.
Ok BINSLOT is normally slot. However in some cases packages are in the
same slot, but not binary compatible (like their libraries having a
different SONAME e.g.
On Fri, Mar 24, 2006 at 01:40:01PM +0200, tvali wrote:
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Thursday 23 March 2006 21:38, Gustavo Sverzut Barbieri wrote:
Cons:
- it's not the final solution to the problem, as said, interfaces
would be better... but interfaces would
On 24/03/06, Brian Harring [EMAIL PROTECTED] wrote:
Checking the interfaces/symbols sucks however, because you can only do
it _after_ you've built whatever you're building (packages do adjust
the defines/typedefs/structs dependant on configure/build options).
As I stated earlier, bincompat
On Friday 24 March 2006 12:40, tvali wrote:
Interface can be made somewhat automatically checkable.
For example:
void a(int);
void b(int, int);
void b(int, char);
Is compatible with:
void a(int);
void b(int, int);
Unfortunately, your wrong. This only makes sure that you have the right
On Friday 24 March 2006 13:10, Brian Harring wrote:
As I stated earlier, bincompat (not binslot paul :P) is the route to
If you want to call it bincompat, I'd have to insist to make it
BINCOMPAT ;-).
go- it gives you up front information so a resolver can plan out what
has to be rebuilt
On 24/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Friday 24 March 2006 12:40, tvali wrote:
Interface can be made somewhat automatically checkable.
For example:
void a(int);
void b(int, int);
void b(int, char);
Is compatible with:
void a(int);
void b(int, int);
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and is there any clear doc of them [as i wouldnt like
to go through them all
tvali wrote:
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and is there any clear doc of them [as i wouldnt like to
On 23/03/06, Alec Warner [EMAIL PROTECTED] wrote:
tvali wrote:
Can someone tell me, which portage python commands should be used or
which kind of file created, if i'm going to test this idea? -- in
beginning, i would like to just add simple deps - are ebuilds the only
place to change and
>From Paul de Vrieze:The semantics that make up the relationships between useflags and the actual
source as goes out of the preprocessor is very complicated. Probably theeasiest way to find it out is to try each permutation and somehow hook intogcc/g++ to get the result of that choice.And that's
On Thursday 23 March 2006 20:53, tvali wrote:
So this interaction is one more thing to get simpler? I'm starting to think
that i should seek for some very-very small part of portage to develop,
because size of things [amount of work], which i already think i should
improve in some way, is
On 23/03/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
Certainly,chroot combined with lvm snapshots would be the easiest way.If you want to focus on binary packages, you might want to start with notdoing it automatically, but using some crude heuristics. You can make it
configurable for when the
Ok... this discussion is missing my initial point that is how to
provide binary dependency and avoid many crashes we have now with
almost no effort.
My initial proposal was to, after compile and before install is done,
we should parse linker information and check for each library it
depends,
On 23/03/06, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
Ok... this discussion is missing my initial point that is how toprovide binary dependency and avoid many crashes we have now withalmost no effort.
Paul was not missing it ;)
Part of his message was for me, part was for you.
I have
This thread keeps going and going and it's a subject thats already been
covered... So I'll just Re you here.
Search the archives here for RRDEPEND, LDEPEND
As soon as I can figure out a way in python to do fast lookups of libs
it will be integrated. I can do it really really fast in c but
I
I was thinking about it, too, and found something i do like maybe more.
It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example, you may depend on fonts
images from another package].
I hope you did read my previous mail of code dependancy -- if not, it's
at the end of message. This here is not so much overthought thing, but
a good starting point, maybe, if code deps are used.
Anyway, i give here the same idea in more complete form and good syntax
(good, because it could be
On Wed, 2006-03-22 at 19:40 +0200, tvali wrote:
I was thinking about it, too, and found something i do like maybe
more. It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example,
2006/3/22, Patrick Lauer [EMAIL PROTECTED]:
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
As an addition to code deps discussion.
I didnt understand exactly, why bin deps were supposed to be better
than what we have now, as i am not yet exactly sure what we have :)
Anyway, i see one basic plus of code deps. It's that you may have huge
number of codelines, all containing #defines and
I'm replying to this one, but I've read the whole thread...
On 3/16/06, Paul de Vrieze [EMAIL PROTECTED] wrote:
On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
Hello,
There is any provision for binary dependency on Gentoo/Portage? The
way it works now is quite messy
On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
Hello,
There is any provision for binary dependency on Gentoo/Portage? The
way it works now is quite messy with things like revdep-rebuild.
I have an idea to solve this problem: after software is build, you
check which files
To make this things worse, the above example assumes that within a slot,
the libraries are binary compatible. There are examples of libraries that
are not. And what about a library whose interface is dependent on a third
library: B uses A, C uses B, but B exports A. So B is dependent on A, and
On Thu, Mar 16, 2006 at 02:58:00PM +0100, Paul de Vrieze wrote:
On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
Hello,
There is any provision for binary dependency on Gentoo/Portage? The
way it works now is quite messy with things like revdep-rebuild.
Solving this is
On Thursday 16 March 2006 15:18, tvali wrote:
To make this things worse, the above example assumes that within a
slot, the libraries are binary compatible. There are examples of
libraries that are not. And what about a library whose interface is
dependent on a third library: B uses A, C
On Thursday 16 March 2006 15:24, Brian Harring wrote:
I would have called bincompat BINSLOT, but the idea is the same.
As per the norm, requires a smart resolver; for c++ would expect
cycles to occur where the only solution is to pull in libstdc++ (fex)
to sidestep horkage while doing the
Hello,
There is any provision for binary dependency on Gentoo/Portage? The
way it works now is quite messy with things like revdep-rebuild.
I have an idea to solve this problem: after software is build, you
check which files it links (ldd binaries libraries) and check the used
against installed
28 matches
Mail list logo
