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 libr
On 24/03/06, tvali <[EMAIL PROTECTED]> wrote:
> On 24/03/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> > On Friday 24 March 2006 12:40, tvali wrote:
> > Perhaps you should read up your knowledge of the C language. After you
> > found that the C language is a mess, try C++, it makes things worse.
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);
> > vo
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 au
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
On 24/03/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
...
is there any good text about sonames and other unix-specific things i
should know about headers and including?
>
> Paul
>
> ps.
>
> > Theory is when you know something, but it doesn't work. Practice is
> > when something works, but you do
On Friday 24 March 2006 12:33, tvali wrote:
>
> I meant headers as .h or .hpp files, which contain function headers.
> They're needed, but they are in many cases, included in pack which
> uses them, even if that means putting some .h's into all libs.
Headers are in the linux/unix world normally no
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, bincom
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 inte
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 demand much more effort and
> > not being automatica
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 S
On Thursday 23 March 2006 21:38, Gustavo Sverzut Barbieri wrote:
> 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
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. openssl-0.9.6 and 0.9.7 (iirc)).
>
> I dont see any me
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 do
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 g
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, which
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 he
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 g
>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
On Thursday 23 March 2006 19:29, tvali wrote:
>
> In c++ code, use flags must definitely have something to do with
> #defines. Otherwise they couldnt do what they do -- so
> uflags=>buildsys=>defines.
>
> Configure, for example, will define set of #defines.
>
> Ok, your answer at least shows that t
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 c
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
go
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
Supposing that you have those
#provide header
lines in all your packages, which provide something (and, of course,
only in those places in code, where they actually do so that useflags
might be correct), there may be some command of dep builder, which just
uses those providings, putting them toget
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 #
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 dependencie
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,
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 add
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].
On 3/20/06, tvali <[EMAIL PROTECTED]> wrote:
> 2006/3/20, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> >
> > I do think you're overcomplicating things where you shouldn't.
> >
> > Declaring stuff manually will always break, and to ensure a safe
> > system, it's better to use compiler information
2006/3/20, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
>
> I do think you're overcomplicating things where you shouldn't.
>
> Declaring stuff manually will always break, and to ensure a safe
> system, it's better to use compiler information.
In all cases, dependancy should be based on interfaces
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 quit
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 re
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
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
> 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,
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 whic
37 matches
Mail list logo