Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On Fri, 31 Dec 2010, Jeroen Roovers wrote: I don't see a reason to deprecate an EAPI, unless you are out to stop a specific feature from being used that was introduced in a later EAPI and breaks the earlier EAPI. Those ebuilds should be converted or otherwise taken care of, but it still wouldn't deprecate the older EAPI as a whole. The package manager has to support all EAPIs indefinitely. And it also doesn't make sense to convert existing ebuilds when half of the tree is still at EAPI 0. The suggestion is that EAPI = 2 should be used for _new_ ebuilds. And yes, the old EAPIs are a burden. For example, changing reverse dependencies if USE dependencies are needed. It's no fun if half of the affected ebuilds have to be changed from EAPI 0 to EAPI 2 in such a case. Ulrich
Re: [gentoo-dev] EAPI 4 specification approved
On 12/31/2010 12:29 PM, Zac Medico wrote: On 12/30/2010 07:37 AM, Petteri Räty wrote: As the text was just approved it will take a while before Package Managers release new versions that declare support for EAPI 4. As such, the new EAPI 4 can't yet be used in the main tree. You will be notified as soon as you can start reaping the benefits. There are portage-2.1.9.27 and 2.2.0_alpha11 releases with EAPI 4 support in the tree now. Please test them. For these who are wondering about the current status we need to have these two bugs (at least) resolved before allowing usage in the tree: https://bugs.gentoo.org/show_bug.cgi?id=322049 https://bugs.gentoo.org/show_bug.cgi?id=211529 Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
* Micha?? Górny mgo...@gentoo.org schrieb: What do you think about this idea ? You mean what do we think about portage-2.2 and preserved-libs? Well, I'm still using portage-2.1, so I wans't aware of whats going on there. For now it seems the preservation is still done explicitly (preserve_old_lib calls in certain ebuilds ?). My proposal is to record the necessary information (eg. which so some executable/so is linked against) automatically - does portage-2.2 do that ? BTW: several blog/maillist postings talked about the problem that even on recompile, older library versions could be linked in even on recompile. Somebody suggested to move away preserved libs to another directly (which is then added to ld.so.conf). What do you think about that ? Another approach could be building everything in an separate, minimal sysroot or chroot. (I admit, I have no idea how complex it would be to implement that in portage - my Briegel buildsystem does always does this) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
On Saturday, January 01, 2011 23:09:11 Enrico Weigelt wrote: BTW: several blog/maillist postings talked about the problem that even on recompile, older library versions could be linked in even on recompile. you'll need to provide an actual example. i have yet to see one. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
On 01/01/2011 08:09 PM, Enrico Weigelt wrote: Well, I'm still using portage-2.1, so I wans't aware of whats going on there. For now it seems the preservation is still done explicitly (preserve_old_lib calls in certain ebuilds ?). My proposal is to record the necessary information (eg. which so some executable/so is linked against) automatically - does portage-2.2 do that ? Yes, portage-2.2 uses /var/db/pkg/*/*/NEEDED.ELF.3 for that. -- Thanks, Zac
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
On Sunday, January 02, 2011 00:17:03 Zac Medico wrote: On 01/01/2011 08:09 PM, Enrico Weigelt wrote: Well, I'm still using portage-2.1, so I wans't aware of whats going on there. For now it seems the preservation is still done explicitly (preserve_old_lib calls in certain ebuilds ?). My proposal is to record the necessary information (eg. which so some executable/so is linked against) automatically - does portage-2.2 do that ? Yes, portage-2.2 uses /var/db/pkg/*/*/NEEDED.ELF.3 for that. although portage has long been generating the NEEDED files in vdb. even stable portage generates these files. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: making revdep-rebuild (partially) obsolete
On Sun, 2 Jan 2011 00:08:34 -0500 Mike Frysinger vap...@gentoo.org wrote: On Saturday, January 01, 2011 23:09:11 Enrico Weigelt wrote: BTW: several blog/maillist postings talked about the problem that even on recompile, older library versions could be linked in even on recompile. you'll need to provide an actual example. i have yet to see one. Not exactly the same thing, but the recent spidermonkey bump changed the lib from libjs.so to libmozjs.so. mediatomb kept finding the old libjs on rebuild. I had to uninstall mediatomb to dump the library and reinstall it. There's not much we can do about stuff like that, but it's not an uncommon occurrence. I usually run into a sticky preserved lib or two every couple months. I still think it's much better than the current portage 2.1 behavior which results in a broken mediatomb. I'll take the rare possibility of a symbol collision over a guaranteed broken package any day. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
