<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="gmail_quote"><div class="Ih2E3d">On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes <<a href="mailto:hughsient@gmail.com" target="_blank">hughsient@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:<br>
> The distro model is nice (and arguably better than the LSB Package API)<br>
> if the packages you like to have are in the repos in sufficiently new<br>
> versions. But if you need to go past that (bleeding edge versions, not<br>
> widely spread apps), things get more difficult currently. Especially<br>
> propietary applications just cannot be distributed by the distros<br>
> directly.<br>
<br>
</div>Right. These packages are compiled against system versions of libraries.<br>
Do we choose the F9 or rawhide version of xulrunner to link against?<br>
There's substantial API and ABI changes between distro versions for the<br>
majority of shared libraries.<br>
<div><br>
> I don't think this is a corner case at all. For one thing, propietary<br>
> applications might just don't play a role _because_ there is no really<br>
> good distribution method for them - the typical chicken-and-egg problem.<br>
<br>
</div>Incorrect. Most closed-source applications I have to use are installed<br>
with an installer binary or script, which just smatters files on the<br>
hard drive in /opt. There's just no need to register these with the<br>
native system package manager as there are no updates repositories nor<br>
dependency tracking required.> </blockquote></div><div><br>You you like an opinion on this, well, that it is mine. For example, look ad Oracle Client 11g<br>application : it. as released with a tarball or so, have on it:<br>

<br>- a full stack of perl <br>- a full stack of shared library : glibc in primisis.<br><br>So what have to do un poor packager manager with this ? Disable the deps and hope the best. Other, as MQ client, are released with RPM : with deps disabled anyway. But not all<br>

are equal : for example websphere. Sure it is tricky to package it but almost don't force me to disable the deps: I DON'T WANT DISABLE THE DEPS.<br><br>IMHO, YMMV as usual<br></div></div>
</blockquote></div><br>