2 Apr
2017
2 Apr
'17
2:49 a.m.
On 04/01/2017 08:06 AM, Bernardo Barros wrote:
On 4/1/17 10:50 AM, Christopher Arndt wrote:
In my opinion, release it, but don't expect a ton of downloads and
testing. ;)
Personally, I think it's better to not depend on unreleased versions of
libraries for release versions of an application. For testing/beta
versions, sure.
Am 29.03.2017 um 08:56 schrieb Chris Cannam:
Would you prefer not having it released? Really? The dependency is on a Cap'n Proto build more
recent than 0.5.3, which
sadly at the moment means a git checkout of it [...].
That's a stupid thing to do for a stable relase of an application, IMHO.
How does the SV project expect distribution package maintainers to
package the application if it depends on unreleased versions of other
software? If it's not "possible" I tend to think
this is a limitation of the
GNU/Linux packaging system, not the developers' negligence.
Hmm, in my opinion, it's the developers choice to either (1) implement a
particular feature that depends on something in the newest version of a
library vs (2) choose to support stable Linux releases. The feature
would have to be really a "must-have" one for me to try to make it work.
It's not a limitation of the Linux packaging system. Library
interdependencies are a thorny issue under any OS. I've run Debian
systems that combined Stable, Testing, Sid and Experimental. Updating
anything was fraught with risk. I've seen Windows library updates that
broke one or more apps that depended on particular libraries.
Questions:
Can't an application be packaged with a static-compiled copy of the
required library, thereby not disturbing other applications that depend
on stable/older library releases?
Does Ubuntu's new Snap system offer anything to help these kinds of
situations?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com