| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 26, 2010 7:33 UTC (Sat) by Tet (subscriber, #5433)In reply to: SELF: Anatomy of an (alleged) failure by dlang Parent article: SELF: Anatomy of an (alleged) failure I'm not claiming fat binaries solve any particular distribution problem, nor do I believe that their existence means that fat binaries must cover every possible combination. In fact, just shipping a combined ia32 and x86_64 binary would cover 99% of the real world machines. But even if you don't want to ship a fat binary, it's not hard to envisage tools that would allow an end user to create a fat binary from two (or more) slim ones. I've outlined a case where it would be both useful and desirable to have them, and to date, I haven't seen any sensible alternatives being proposed.
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 15:08 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Just use two binary packages, with non-architecure-dependent stuff exactly the same, and arrange for the package manager to manage files belonging to several packages. RPM does this, and it works. No need to screw around with the kernel, no need to have 3 versions of the package (arch 1, arch 2, fat).
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 18:20 UTC (Sat) by tzafrir (subscriber, #11501) [Link]
It works for rpm when all those shared fiels are identical in every package.
But what you want to do here is that rpm will be able to merge files from different packages into a single file on disk. This won't work.
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 21:49 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
and fat binaries won't work in cases where you need different config file options for different architectures and the config file is on a shared drive
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 16:11 UTC (Sun) by Tet (subscriber, #5433) [Link] <paxman>Answer the question! </paxman> Your "solution" doesn't solve the problem where application plugins are concerned. Firstly, the majority them are not installed using the system package manager in the first place, and secondly, it's utterly irrelevant anyway. You can't package the achitecture specific bits separately, because the application only looks for them in one place. As I said right at the start, it would be good to fix the applications, but there are a hell of a lot of them. Fat binaries would solve the problem. Your suggestions wouldn't, without first also patching the apps.
|
|||||||||||||