| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 25, 2010 22:17 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: SELF: Anatomy of an (alleged) failure by Tet Parent article: SELF: Anatomy of an (alleged) failure
people supporting want a Fat binary that's only fat enough for your particular system, but claim that having fat binaries would solve distribution problems because there wouldn't need to be multiple copies.
these two conflict, if you are going to support FAT binaries for every possible combination of options the distribution problem is much larger. If you are going to want the fat binary to support every possible system in a single binary it's going to be substantially larger.
it's not that I am so opposed to the idea of fat binaries as it is I don't see them as being that useful/desirable. the problems they are trying to address seem to be solvable by other means pretty easily, and there is not much more than hand waving over the cost.
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 26, 2010 7:33 UTC (Sat) by Tet (subscriber, #5433) [Link] 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.
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.
|
|||||||||||||