On Tue, 2009-02-17 at 23:23 -0500, Jon Masters wrote: > What I meant was that, although on the face of it you can just link > against i386 or i586 and the ABI compatibility will see you through, > there are probably packages that have build hacks which will break > horribly on discovering that i586 has been substituted. Some of those > will be due to some binary munging, others will be more along the lines > of what was already raised. I think that's something that should be tested and discovered, rather than swept under the rug with an ordered build or second build. > > > > And what will happen when something wants a static > > > library file to link against? > > > > This one is a little bit more interesting, perhaps everything that is > > static should get a second rebuild pass. Of course, now I'm going to > > want a good programmatic way of discovering what is statically compiled, > > preferably without having to look at the binaries themselves. > > Indeed. This was my *primary* concern (but the above one should not be > ignored) and I think gives serious cause to do a second rebuild for good > measure. I would at the very least suggest a complete second pass just > to be 100% certain that a). everything was caught that might break > builds later b). there isn't something built static that is using i386 > code when we "promised" i586. > > You're doing a great job...and I'm sorry to sound like a grumbler :) I'm > just trying to get more involved with this side of things. Can I propose > a complete second rebuild rather than a piecemeal rebuild as a > compromise to doing some kind of full ordering based build process? > Unless you think there's not time for a complete second pass...in which > case I'll try to think of alternatives. If this is really a strong concern, the second pass should only be for things that are compiled, not noarch items. Could potentially narrow it down even more. > > I don't have a good way to search for static linking without examining > bins, but I've got a cold and feel like utter poo, so maybe I'm missing > something! > I think when the static guidelines were put in place, it was so that we could easily discover the static packages, this being one of the reasons. However I'm pretty far removed from the guidelines work these days and I don't recall what specifically we're to use to discover static packages. I think the most I'd be willing to do would be a second build pass across the static packages. IMHO everything else should be left up to testing discovery and fixing the assumptions rather than hiding them. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
