On Saturday 30 September 2006 15:34, Brian Harring wrote:
If that's what folks want, sure, but what you're proposing is just
sliding NEEDED in as the defacto solution without labeling it as such.
no idea what this means
Re-read your emails, and mine please. The scenario I pointed out was
On Wednesday 27 September 2006 03:54, Brian Harring wrote:
On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote:
as i said, if you have changed ABI without an ABI bump, then the upstream
package maintainer is screwing everyone who uses the package, not just
Gentoo ... so perhaps
On Sat, Sep 30, 2006 at 02:01:08PM -0400, Mike Frysinger wrote:
On Wednesday 27 September 2006 03:54, Brian Harring wrote:
Bleh, this is getting back to exactly my point that it's unbounded
resolution. To support this, every step of execution would require
scanning for dangling nodes
On Monday 25 September 2006 14:16, Brian Harring wrote:
Bad soname handling is just *part* of what BINCOMPAT could do; it's
not the sole reason for it's existance, as such it's not quite right
dismissing it just because it addresses a rarity the NEEDED approach
doesn't. :)
i dismiss it as
On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote:
On Monday 25 September 2006 14:16, Brian Harring wrote:
Bad soname handling is just *part* of what BINCOMPAT could do; it's
not the sole reason for it's existance, as such it's not quite right
dismissing it just because it
On Saturday 23 September 2006 10:30, Brian Harring wrote:
dlopen?
we already said that this will need a new depend variable
How does this fix openssl horkage? (bad soname handling)
it wont, but such things are broken regardless outside of Gentoo ... and
trying to accommodate something that
On Saturday 23 September 2006 22:36, Ciaran McCreesh wrote:
How would it know what other files are required? For example, if
libexpat.so.0 were to rely upon /usr/share/expat-0/config , how would
the package manager know not to clobber that file? Or are you
suggesting leaving (or reparenting,
On Sat, Sep 23, 2006 at 11:31:12PM -0400, Mike Frysinger wrote:
On Saturday 23 September 2006 10:30, Brian Harring wrote:
dlopen?
we already said that this will need a new depend variable
How does this fix openssl horkage? (bad soname handling)
it wont, but such things are broken
On Thursday 21 September 2006 13:15, Alin Nastac wrote:
Unless you save the specific compatibility version of the net-dialup/ppp
used by net-dialup/pptpd for building the package, I don't see how can
it help me.
Judging after /var/db/pkg content, I have no such information.
it is all there
On Thursday 21 September 2006 11:41, Duncan Coutts wrote:
On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 10:56, Duncan Coutts wrote:
If we do go in this direction it'd be great to be able to slot on the
ABI and still have dependencies resolved
On Saturday 23 September 2006 06:35, Duncan Coutts wrote:
I was worried from your ABI/API comments that you meant that we should
never be allowed to do it.
i was commenting on the more general case; SLOTing something that wasnt meant
to be SLOTed
-mike
pgpQseGjV9xuk.pgp
Description: PGP
On Sat, Sep 23, 2006 at 06:20:44AM -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 11:08, Brian Harring wrote:
On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote:
i'm referring to the specific file of course, not anything else in the
package ... so integrating the
On Saturday 23 September 2006 09:14, Brian Harring wrote:
You're assuming that after the merge of the pkg that breaks
compatibility, building is actually _still_ possible for the depends.
of course i am; i just said that portage would make sure to not unmerge any
ABI lib still in use
We
On Saturday 23 September 2006 09:50, Mike Frysinger wrote:
On Saturday 23 September 2006 09:14, Brian Harring wrote:
We don't classify our deps as actual build depends vs link depends; as
such trying to (essentially) patch things up after allow for the
scenario where merging breaks the
Mike Frysinger wrote:
On Thursday 21 September 2006 13:15, Alin Nastac wrote:
Unless you save the specific compatibility version of the net-dialup/ppp
used by net-dialup/pptpd for building the package, I don't see how can
it help me.
Judging after /var/db/pkg content, I have no such
On Sat, Sep 23, 2006 at 09:50:12AM -0400, Mike Frysinger wrote:
On Saturday 23 September 2006 09:14, Brian Harring wrote:
You're assuming that after the merge of the pkg that breaks
compatibility, building is actually _still_ possible for the depends.
of course i am; i just said that
On Saturday 23 September 2006 10:24, Alin Nastac wrote:
I see only libraries in NEEDED and it is probably generated
automatically. There is no way for the automatic tools to discover the
dependency between pptpd and ppp version.
that gets back to ABI versus dynamic plugins ... we already know
On Sat, Sep 23, 2006 at 10:34:03AM -0400, Mike Frysinger wrote:
On Saturday 23 September 2006 10:24, Alin Nastac wrote:
I see only libraries in NEEDED and it is probably generated
automatically. There is no way for the automatic tools to discover the
dependency between pptpd and ppp
On Thu, 21 Sep 2006 11:01:40 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| On Thursday 21 September 2006 10:54, Donnie Berkholz wrote:
| Yes, I agree with you. For example, take expat. The maintainers have
| refused to allow both versions to exist simultaneously on a system
| because it
I'm annoyed about impossibility to fix a certain class of breakages
(other than reemerging the failing package). I am referring to the
breakages occurred when foo has been upgraded, but the bar package
cannot work with it because it was build against the old foo version.
We all had to run
Alin Nastac wrote:
I reckon this could be solved by yet another *DEPEND variable. The only
atoms accepted by this variable would be CATEGORY/PN. Every time when
a package gets updated from PV1 to PV2 (distinct versions, revisions
will not count), portage will automatically re-emerge those
On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
Alin Nastac wrote:
I reckon this could be solved by yet another *DEPEND variable. The only
atoms accepted by this variable would be CATEGORY/PN. Every time when
a package gets updated from PV1 to PV2 (distinct versions, revisions
Luca Barbato wrote:
Alin Nastac wrote:
I reckon this could be solved by yet another *DEPEND variable. The only
atoms accepted by this variable would be CATEGORY/PN. Every time when
a package gets updated from PV1 to PV2 (distinct versions, revisions
will not count), portage will automatically
On Thursday 21 September 2006 06:35, Alin Nastac wrote:
For instance, the recent openssl-0.9.8* update broke dev-libs/neon (and
consequently subversion) because neon library isn't happy just by
linking with libssl.so.0.9.7 but also check the libssl version when
loads the ssl library. Another
On Thursday 21 September 2006 07:59, Brian Harring wrote:
Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
compatible, but 0.9.7d isn't. If you force an automatic algo that
tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
end result being folks likely
On Thu, Sep 21, 2006 at 09:52:27AM -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 07:59, Brian Harring wrote:
Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
compatible, but 0.9.7d isn't. If you force an automatic algo that
tries to (effectively) guess, you
Mike Frysinger wrote:
On Thursday 21 September 2006 07:59, Brian Harring wrote:
Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
compatible, but 0.9.7d isn't. If you force an automatic algo that
tries to (effectively) guess, you get a lot of rebuilds through a,b,c,
end
Brian Harring wrote:
On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
There is one flaw with this though; packages can provide both
libraries _and_ binaries. Our dependencies don't represent whether
the dep is actual linkage, or just commandline consuming, so (using
the
On Thursday 21 September 2006 10:14, Donnie Berkholz wrote:
Not adding it into the ebuild means that it's impossible to show in
advance what packages will actually be installed, because you don't know
whether the sover will bump.
sometimes you dont know as the ABI bump may be arch or feature
On Thursday 21 September 2006 10:04, Brian Harring wrote:
I agree; while I'm labeling it ABI, includes both bad soname handling
and seperate sonames.
those people should be smacked (for the interest of disclosure, i have
violated the bad soname rule for the sake of following upstream)
Feel
On Thursday 21 September 2006 10:38, Alin Nastac wrote:
Brian Harring wrote:
There is one flaw with this though; packages can provide both
libraries _and_ binaries. Our dependencies don't represent whether
the dep is actual linkage, or just commandline consuming, so (using
the openssl
Mike Frysinger wrote:
On Thursday 21 September 2006 10:14, Donnie Berkholz wrote:
Not adding it into the ebuild means that it's impossible to show in
advance what packages will actually be installed, because you don't know
whether the sover will bump.
sometimes you dont know as the ABI bump
On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 07:59, Brian Harring wrote:
Why have the explicit var? Because 0.9.7a through 0.9.7c may all be
compatible, but 0.9.7d isn't. If you force an automatic algo that
tries to (effectively) guess, you get a
On Thursday 21 September 2006 10:54, Donnie Berkholz wrote:
Yes, I agree with you. For example, take expat. The maintainers have
refused to allow both versions to exist simultaneously on a system
because it apparently causes more breakage than just breaking every app
on your system by removing
On Thu, Sep 21, 2006 at 05:38:08PM +0300, Alin Nastac wrote:
Brian Harring wrote:
On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote:
There is one flaw with this though; packages can provide both
libraries _and_ binaries. Our dependencies don't represent whether
the dep
On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 10:04, Brian Harring wrote:
I agree; while I'm labeling it ABI, includes both bad soname handling
and seperate sonames.
those people should be smacked (for the interest of disclosure, i have
Duncan Coutts wrote:
So for it's something like:
# for C:
ABI=${SONAME}
# for python
ABI=${PY_PV}
# for haskell:
ABI=${GHC_PV}
paludis has something going in this direction but I don't think it'd
quite solve the python/ghc abi issue. It was aimed more at cases like
mips with it's
On Thursday 21 September 2006 10:56, Duncan Coutts wrote:
If we do go in this direction it'd be great to be able to slot on the
ABI and still have dependencies resolved correctly. For example imagine
having parallel python-2.3 and 2.4 installations with some libs
installed for both. Crucially,
On Thu, 2006-09-21 at 11:11 -0400, Mike Frysinger wrote:
On Thursday 21 September 2006 10:56, Duncan Coutts wrote:
If we do go in this direction it'd be great to be able to slot on the
ABI and still have dependencies resolved correctly. For example imagine
having parallel python-2.3 and 2.4
Brian Harring wrote:
BDEPEND was actually a seperate proposal/idea, intention there was to
have that be the deps that *must* be CHOST (gcc would be an example);
bits that are used to actually build the pkg, not data it consumes in
building (headers would be data).
Well, until now I
Mike Frysinger wrote:
i think you're merging the two issues you brought up ... there is binary ABI
issues (which should not require a new DEPEND variable as portage can extract
that information out at runtime) and there is runtime plugin issues with
packages using dlopen() (which portage
Duncan Coutts wrote:
So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do useful things that
we cannot currently do.
what about making them build what
On Thu, Sep 21, 2006 at 08:15:48PM +0300, Alin Nastac wrote:
Brian Harring wrote:
BDEPEND was actually a seperate proposal/idea, intention there was to
have that be the deps that *must* be CHOST (gcc would be an example);
bits that are used to actually build the pkg, not data it consumes
On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote:
Duncan Coutts wrote:
So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do useful things
Duncan Coutts wrote:
On Thu, 2006-09-21 at 20:27 +0200, Luca Barbato wrote:
Duncan Coutts wrote:
So my point is, I don't think it can be simply dismissed as ABI nonsense
that we don't have to deal with. Being able to SLOT on the compiler
flavour (and possibly version) would allow us to do
45 matches
Mail list logo
