[gentoo-dev] [RFC] Multilib ABI identifiers for NEEDED.ELF.2 (GLEP 64) and binary package soname dependencies
Hi,
While research requirements for binary package soname dependencies [1],
I found that the NEEDED.ELF.2 data that portage generates contains
insufficient information to uniquely distinguish all of the multilib
ABIs that may be present on a given system [2]. In order to correctly
handle multilib ABIs for binary package soname dependencies,
preserve-libs, and other possible applications involving GLEP 64 [1], we
will need more information than is currently recorded in NEEDED.ELF.2.
In order to solve this problem, I propose that we extend NEEDED.ELF.2 to
include a new field containing a multilib ABI identifier. The extension
will be backward-compatible, and NEEDED.ELF.2 will only need to be
regenerated on systems with multilib ABIs that are otherwise
indistinguishable (multilib x32 and mips systems).
The naming convention for the multilib ABI identifiers can be derived
from the set of abi_* USE flags that has been established by the
gx86-multilib project [4]. For example, if we exclude the abi_ prefix,
and apply this convention to all supported architectures, then the
complete set of multilib ABI identifiers will be as follows:
alpha_{32,64}
arm_{32,64}
hppa_{32,64}
ia_{32,64}
m68k_{32,64}
mips_{eabi32,eabi64,n32,n64,o32,o64}
ppc_{32,64}
s390_{32,64}
sh_{32,64}
sparc_{32,64}
x86_{32,64,x64}
The ABIs referenced by some of the above *_32 and *_64 identifiers may
be imaginary, but they are listed anyway, since the goal is to establish
a naming convention that is as consistent and uniform as possible. The
OS is notably absent from these identifiers, since OS-independence is
one of the goals. The assumption is that, for a given installation, we
are only interested in tracking multilib ABIs for a single OS.
I have attached a python script to bug 534206 [2] that can serve as a
reference implementation, demonstrating how a file's ELF header can be
used to compute a suitable multilib ABI identifier.
Please respond with any feedback that you may have about this proposal.
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/94145
[2] https://bugs.gentoo.org/show_bug.cgi?id=534206
[3] https://wiki.gentoo.org/wiki/GLEP:64
[4] https://wiki.gentoo.org/wiki/Gx86-multilib
--
Thanks,
Zac
Re: [gentoo-dev] [RFC] Multilib ABI identifiers for NEEDED.ELF.2 (GLEP 64) and binary package soname dependencies
On 03-01-2015 01:24:48 -0800, Zac Medico wrote: > In order to solve this problem, I propose that we extend NEEDED.ELF.2 to > include a new field containing a multilib ABI identifier. The extension > will be backward-compatible, and NEEDED.ELF.2 will only need to be > regenerated on systems with multilib ABIs that are otherwise > indistinguishable (multilib x32 and mips systems). Wouldn't it be a good idea to use NEEDED.ELF.3 for this? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Gentoo-sources - should we stable?
El vie, 02-01-2015 a las 12:25 -0500, Mike Pagano escribió: > Hello, Everyone, > > Are there solid arguments for stabilizing any version of gentoo-sources? I > think the valid arguments for not stabilizing gentoo-sources can be garnered > from the thread about not stabilizing vanilla-sources[1]. > > This is in no way complaining about how long it takes to stabilize a kernel. > It's just a fact that by the time we do stabilizing one, there might be many, > many kernel versions released for that 3.X branch that contains security > fixes > for which the stable version will not have. Kernel versions are coming out > 1-2 a week at this point. > > I feel we are giving users a false sense of security, and maybe it would be > better for them to upgrade faster than they are doing now if they are only > using stable kernels. > > Having stable kernels around keeps me from deleting these old, potentially > vulnerable releases.[2] > > Mike > > [1] http://marc.info/?l=gentoo-kernel&m=137182668616082&w=2 > [2] http://packages.gentoo.org/package/sys-kernel/gentoo-sources > > In my case I still run only "stable" gentoo-sources in many machines to prevent regressions introduced by new major kernel releases. For example, few weeks ago kernel 3.17.x were breaking X in some of them due to a regression with AGP handling that was fixed in 3.17.4. Even if arch team members cannot test the versions really deep, for now it has been enough for me to rely on kernel maintainers thinking a concrete major version is ready to be stabilized after some weeks :)
[gentoo-dev] Re: Gentoo-sources - should we stable?
Mike Pagano posted on Fri, 02 Jan 2015 15:46:21 -0500 as excerpted: > We have had a lot of stable kernels with a not-so-stable btrfs. That's > a whole conversation in itself. There are pieces of the kernel that are > in a, shall we say, less stable state than others. On btrfs FWIW... As a gentoo/~arch btrfs user myself and reasonably active on the btrfs list, I'd *never* recommend btrfs in anything like its current state to a gentoo-stable user. Just tonite, before I switched to this list I was on the btrfs list, and I just got thru posting a reply to someone running ubuntu with a 3.13 series kernel, suggesting they upgrade to something newer than the paleolithic. I'll repeat what I said there. There are valid reasons to wish to stick with a tested stable system, but those reasons and the reasons one would choose btrfs in its current state simply collide, because it's anything but fully stable. Thus, one must choose, either a different filesystem if one wants to run old and known stable, or btrfs, but do try to keep up, tho not necessarily the /latest/ stable series, one back and following the list so as to know if there's problems with the current stable before you upgrade, seems to be the sweet spot. Regardless, btrfs is not yet any place for stable-arch gentooers to play. xfs seems to be the commonly recommended stable alternative these days, while at least since data=ordered by default, I've had extremely good luck with reiserfs, which I continue to use for my own off-btrfs backups. (FWIW I'm not the only one a bit leery of ext3/4. I was surprised at how few folks recommend it as a stable alternative to btrfs. For those interested in stability, xfs really does seem to be the best recommended filesystem out there at this point.) So btrfs is really out of context for this discussion, centered on kernel stable keywording as it is. If you've reason to stick with stable, you've reason to choose something other than btrfs, and that's likely to remain the case for, I'd say, another year at least, tho things /are/ getting better... slowly... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Gentoo-sources - should we stable?
On Sat, Jan 3, 2015 at 6:33 AM, Duncan <1i5t5.dun...@cox.net> wrote: > As a gentoo/~arch btrfs user myself and reasonably active on the btrfs > list, I'd *never* recommend btrfs in anything like its current state to a > gentoo-stable user. Just tonite, before I switched to this list I was on > the btrfs list, and I just got thru posting a reply to someone running > ubuntu with a 3.13 series kernel, suggesting they upgrade to something > newer than the paleolithic. Well, everybody has their preferences, but my sense is that somebody that you consider a candidate for Gentoo stable probably shouldn't be running Gentoo at all. I tend to run stable because I LIKE to run bleeding-edge packages, but I want to pick which ones are bleeding edge. Btrfs is one that I'm interested in so I'll go ahead and take the risks and follow upstream closely. On the other hand, I'm not that interested in running the latest and greatest mysql, and I'd prefer not to have to stay on top of all their bleeding-edge issues as well. The thing that Gentoo gets you that virtually no other distro does is the ability to mix keywords. Sure, you're less tested/supported in that configuration, but in my experience there are almost never issues and when they are they tend to be build issues and not runtime issues, so the pain is minor and obvious. In any case, whether you run btrfs or not the general principle is for stable users to not run the very latest kernel branch the day it is released. Longterm does that reasonably well, and it gets btrfs backports just like all the others. -- Rich
Re: [gentoo-dev] Gentoo-sources - should we stable?
On Saturday, January 03, 2015 11:18:26 AM Pacho Ramos wrote: > El vie, 02-01-2015 a las 12:25 -0500, Mike Pagano escribió: > > Hello, Everyone, > > > > [2] http://packages.gentoo.org/package/sys-kernel/gentoo-sources > > In my case I still run only "stable" gentoo-sources in many machines to > prevent regressions introduced by new major kernel releases. For > example, few weeks ago kernel 3.17.x were breaking X in some of them due > to a regression with AGP handling that was fixed in 3.17.4. > > Even if arch team members cannot test the versions really deep, for now > it has been enough for me to rely on kernel maintainers thinking a > concrete major version is ready to be stabilized after some weeks :) Hi, Pacho, I think if you read further in the thread and find Ian's suggestion, it should cover your needs nicely. Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] [RFC] Multilib ABI identifiers for NEEDED.ELF.2 (GLEP 64) and binary package soname dependencies
On 01/03/2015 01:50 AM, Fabian Groffen wrote: > On 03-01-2015 01:24:48 -0800, Zac Medico wrote: >> In order to solve this problem, I propose that we extend NEEDED.ELF.2 to >> include a new field containing a multilib ABI identifier. The extension >> will be backward-compatible, and NEEDED.ELF.2 will only need to be >> regenerated on systems with multilib ABIs that are otherwise >> indistinguishable (multilib x32 and mips systems). > > Wouldn't it be a good idea to use NEEDED.ELF.3 for this? I don't think it's worth the trouble to burden all users with the need to generate a new file for all of their installed and binary packages, especially since the existing NEEDED.ELF.2 format is already sufficient to distinguish multilib ABIs an all systems except for multilib x32 and mips systems. By extending NEEDED.ELF.2, we can eliminate migration hassles for the vast majority of users. -- Thanks, Zac
Re: [gentoo-dev] Gentoo-sources - should we stable?
El sáb, 03-01-2015 a las 10:14 -0500, Mike Pagano escribió: [...] > Hi, Pacho, > > I think if you read further in the thread and find Ian's suggestion, it > should > cover your needs nicely. > > Mike > Yeah, that suggestion looks nice to me, thanks :)
[gentoo-dev] last rites: dev-libs/libgeier
# Hanno Boeck (03 Jan 2015) # Was a dependency of taxbird which has been replaced by # geierlein. As this requires yearly changes it's unlikely # it has any use for anyone. Masked for removal. dev-libs/libgeier -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-dev] last rites: dev-libs/libgeier
# Hanno Boeck (03 Jan 2015) # Was a dependency of taxbird which has been replaced by # geierlein. As this requires yearly changes it's unlikely # it has any use for anyone. Masked for removal. dev-libs/libgeier -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-dev] Last rites: app-emulation/wine-doors
# Hanno Boeck (03 Jan 2015) # dead upstream, masked for removal app-emulation/wine-doors If anyone wants to fix this: It requires downloads from upstream's webpage, so it's likely impossible to take over without replacing upstream entirely. Open bugs: https://bugs.gentoo.org/show_bug.cgi?id=519270 https://bugs.gentoo.org/show_bug.cgi?id=277491 -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-dev] Re: Gentoo-sources - should we stable?
Rich Freeman posted on Sat, 03 Jan 2015 07:53:56 -0500 as excerpted: > In any case, whether you run btrfs or not the general principle is for > stable users to not run the very latest kernel branch the day it is > released. Longterm does that reasonably well, and it gets btrfs > backports just like all the others. I strongly agree that LTS stables as discussed are the way to go for gentoo-sources. In terms of btrfs, however, not everything is backported, and while LTS is fine as long as things are running well, when people run into problems and post to the list, if they're back some versions, trying with current tends to be the first suggestion. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
