Re: [gentoo-dev] RFC about another *DEPEND variable
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 right now actually :) check out the NEEDED file ... combine that with CONTENTS of other packages, and you have all the binding info you want ... -mike pgp8bgoWaDBYG.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 correctly. For example imagine having parallel python-2.3 and 2.4 installations with some libs installed for both. Crucially, deps need to be resolved to the version of a lib with the right ABI. ugh, no ... we are not a binary distribution so we should not have to worry about ABI baggage So we can't ever install two versions of python or ghc at once? That seems a shame. that's an issue for the python or ghc maintainers to address -mike pgpXbGNFGDdo9.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 hack eutils.eclass:preserve_old_lib() into portage so it isnt a hack (not a knock against the current implementation here; it's always going to be a hack until portage manages proper unmerging of the ABI library) The reason folks aren't talking about using NEEDED is that NEEDED data is generated _after_ building; as well it should be ... trying to enumerate the linking ABI possibilities before hand is not doable and not worth wasting the time of maintainers when it can be automated getting the info into the resolver up front allows for a helluva lot more options, and makes stuff like ensuring you have all sources required downloaded *prior* actually simple to do, rather then inserting recalculating hacks into the resolver. rather than integrating it all into the resolver in a one-pass system, a two pass system would work: - build all the packages requested - after each package, if an ABI library is being removed, check to see if it is needed by any other package. if it is needed, record it and preserve it and move on You're assuming that after the merge of the pkg that breaks compatibility, building is actually _still_ possible for the depends. 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 toolchain, thus building isn't possible. Because we don't classify the type of build time dep, that means each DEPEND match must have it's run time depends (RDEPEND) satisfied prior to being usable as a DEPEND; that right there punches a whole in the delay till the end approach, and is a good example of what I mean when I say this is unbounded resolution; the only way to solve it is to redo the resolution between finished building and merging the pkg to determine if it will break any required DEPENDS for later steps. - once all the packages requested have been merged, you start the second phase and calculate everything that needs to be rebuilt. as ABI libs are no longer needed on a system, portage can scrub them out as ABI libs are no longer needed on a system, phrasing of that implies you're suggesting that portage should leave the older package in place till it's updated all revdeps, then wipe it. Which is fairly nasty, especially if you factor in the user potential of ctrl+c'ing it. Finally, if I'm interpretting your statement there correctly, still isn't guranteed to work- just having the lib around doesn't mean that the older package is left in a working state with the new partially merged over it, only way that would work is if the two were slotted (indicating they could coexist on disk). ~harring pgpW99BPE62sk.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 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 toolchain, thus building isn't possible. huh ? RDEPEND is linktime ... see my statement above - once all the packages requested have been merged, you start the second phase and calculate everything that needs to be rebuilt. as ABI libs are no longer needed on a system, portage can scrub them out as ABI libs are no longer needed on a system, phrasing of that implies you're suggesting that portage should leave the older package in place till it's updated all revdeps, then wipe it. no i am not; read my previous e-mails where i said it would leave behind the 1 ABI lib required ... aka whatever is encoded in SONAME -mike pgpyAGCZ2QnUO.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 toolchain, thus building isn't possible. huh ? RDEPEND is linktime ... see my statement above lemme rephrase ... you keep the ABI SONAME lib around until all packages are done with it; this does not affect any other package (including upgrades to the same package) as the ABI filename is unique in the filesystem it is not used at linktime because it does not provide a linkable file ... it merely provides the library used at runtime so you can upgrade on the fly as the old ABI lib does not conflict with anything -mike pgpWyxlIfwykH.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 information. it is all there right now actually :) check out the NEEDED file ... combine that with CONTENTS of other packages, and you have all the binding info you want ... 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. Besides, even if I would have somehow /usr/lib/ppp/2.4.3 in NEEDED file of the pptpd, the amount of computation needed to discover which package offers such thing would be prohibitive. The reciprocal operation (find which packages use the old path before upgrade) would also be prohibitive. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 portage would make sure to not unmerge any ABI lib still in use dlopen? How does this fix openssl horkage? (bad soname handling) Also... what do we do for python/perl (*-updater scripts in general) where a change in a pkg state means we have to rebuild the revdeps? What you're suggesting works for strictly linkage; still think this shouuld work for the general problem rather then just one subset. 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 toolchain, thus building isn't possible. huh ? RDEPEND is linktime ... see my statement above RDEPEND is execution requirements; to use the binary, this is what needs to be in the graph. Clarifying my statement; we don't break our DEPEND down into this is what is executed in building the package (toolchain), vs this is the crap the binaries we build against need avail to be linked against, literally what winds up as -l args. If punting the old lib (as I assumed), means we would potentially be making certain DEPEND atoms unusable if they're required in an execution context (rather then just winding up as a -l arg). So... ignore that bit since you're talking about lingering files. - once all the packages requested have been merged, you start the second phase and calculate everything that needs to be rebuilt. as ABI libs are no longer needed on a system, portage can scrub them out as ABI libs are no longer needed on a system, phrasing of that implies you're suggesting that portage should leave the older package in place till it's updated all revdeps, then wipe it. no i am not; read my previous e-mails where i said it would leave behind the 1 ABI lib required ... aka whatever is encoded in SONAME Yeah, missed the presvered (woot for 5am wakeup). In that case, wouldn't mind a response to the what about ctrl+c during the run? The potential for orphaning there sucks; recording the old library in the new version sucks also since it complicates the merge process, that lib *must* be removed else it's a potential collision-protect minefield. Finally, even if the lib is temporarily left behind, this solution doesn't gurantee the library actually would *work* still- it only can work if the lib is standalone from the rest of the pkg and doesn't rely on any external data from the pkg. Example would be pkg foobar that internally has libconvience, used by it's libs but not externally linked, contains (oddly enough) convience bits shared across foobars libraries. libconvience is *not* to be externally linked against, consumers must access the other libs (say libfoo); any soname bumps to libfoo, the old version gets broke in the process despite due to it linking internally against an unversioned so. Granted, semi retarded, but gnomes libegg comes to mind as a potential case of this. Basically trying to point out that what you're proposing only works in a subset of the cases revdep must deal with, and that revdep itself doesn't deal with *all* situations as is; hence BINCOMPAT as a way to try and shift it under maintainers control. Maintainence of it *should* be pretty simple also; for sane upstream soname handling, you just bump it with the majors; for the rest, its a knob that can be fiddled to at least give up front warning of the issue. ~harring pgphglIgSikSW.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 we'll need a
new DEPEND to track dlopen-ed plugins
Besides, even if I would have somehow /usr/lib/ppp/2.4.3 in NEEDED file
of the pptpd, the amount of computation needed to discover which package
offers such thing would be prohibitive. The reciprocal operation (find
which packages use the old path before upgrade) would also be prohibitive.
no it wouldnt ... when you merge a package, you record all the SONAME's it
provides:
scanelf -qRS ${D} SONAME
in fact, running `scanelf -qlpRS` doesnt take that long on my machine
-mike
pgpvTUPVCKbO6.pgp
Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 version.
that gets back to ABI versus dynamic plugins ... we already know we'll need a
new DEPEND to track dlopen-ed plugins
Besides, even if I would have somehow /usr/lib/ppp/2.4.3 in NEEDED file
of the pptpd, the amount of computation needed to discover which package
offers such thing would be prohibitive. The reciprocal operation (find
which packages use the old path before upgrade) would also be prohibitive.
no it wouldnt ... when you merge a package, you record all the SONAME's it
provides:
scanelf -qRS ${D} SONAME
in fact, running `scanelf -qlpRS` doesnt take that long on my machine
Flush the cache... Makes a world of difference. Additionally, he is
talking about what is *done* with that data after the fact, iow other
words walking the entire vdb to find all affected pkgs. Can pretty
much gurantee after a build that data isn't likely to be available
(part of the reason portageq calls during building are slow).
Could collapse that into a simple mapping, but that introduces
backwards compatibility issues...
~harring
pgpa8FBw1B83Y.pgp
Description: PGP signature
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation.2006/9/24, Ryan Hill [EMAIL PROTECTED]:Mike Frysinger wrote: oss is dead, why bother going with it in default USE anymore ?alsa forever ! i think the standard argument is games.i've never needed it though.--de.
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
On Sunday 24 September 2006 00:13, Christoph Mende wrote: No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation. That requires oss useflag on alsa-driver. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6VpgkYXSuf.pgp Description: PGP signature
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
Well ok, I don't use alsa-driver ;)2006/9/24, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED]: On Sunday 24 September 2006 00:13, Christoph Mende wrote: No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation.That requires oss useflag on alsa-driver. --Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
Diego 'Flameeyes' Pettenò wrote: On Sunday 24 September 2006 00:13, Christoph Mende wrote: No game I've installed here needs any package with the oss USE flag, those packages that use OSS are fine the ALSA OSS Emulation. That requires oss useflag on alsa-driver. How bout changing this flag to aoss and making it new default instead of oss? mozilla-launcher already has an aoss flag. Or wait for per-package USE defaults and use it for oss in alsa-driver as an exception. -- Vlastimil Babka (Caster) Gentoo/Java -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: default USE flags in profiles (oss)
On Sunday 24 September 2006 03:21, Vlastimil Babka wrote: How bout changing this flag to aoss and making it new default instead of oss? mozilla-launcher already has an aoss flag. A flag that I don't like at all, as it should have probably been alsa, but it was difficult to implement without proper usable package.use.mask (will take time before we can actually use it). This because aoss doesn't enable ALSA's *oss emulation*, but uses media-libs/alsa-oss to provide an indirection layer that filters accesses to DSP devices to move the data to ALSA. A similar thing is done by esddsp, artsdsp, padsp. Or wait for per-package USE defaults and use it for oss in alsa-driver as an exception. Yes this is feasible, but for the time being I'd rather not have to receive in my [EMAIL PROTECTED] folder two bugs a day about people wanting OSS emulation in alsa-driver. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpebHWnWNzsa.pgp Description: PGP signature
Re: [gentoo-dev] RFC about another *DEPEND variable
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 apparently causes more breakage than just breaking every | app on your system by removing .so.0. | | that is the exact case portage should be handling for you | | it would go oh hey, check out libexpat.so.0 ... some things seem to | want it ... HEY USER, you need to rebuild: ... once all the | packages still consuming libexpat.so.0 are rebuilt, portage could | silently trim it from the system | | complicated ? not really, scanelf can produce all this information | in an easily digestable format 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, if you prefer) all a package's files, not just the .so files? Or a related question: what proportion of breakages will be fixed merely by keeping .so files and nothing else around? Will implementing this prevent enough breakages to make it worthwhile? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
