Can Ministro work for non-QT libraries?
Bill Cox
shared libraries between apps a major flaw, one that not just causes
code bloat, but which causes us to port/rewrite the same functionality
over and over. Just take MP3 decoders for example... how many ports
are there?
Would it be possible to use Ministro to share more libraries, not just
QT? There are all sorts of open-source packages that Android
developers would love to share, if we just had a decent way to do it.
Thanks,
Bill
Yaman Umuroglu
the libraries as far as I know. However, things like checking the
required vs downloaded library version, capabilities for using
different library repositories and more strict error checking should
be implemented before Ministro becomes more mainstream and serves more
generic library management purposes IMO.
Yaman
Sergey A. Galin
О©╫О©╫., 04/03/2011 О©╫ 04:51 -0800, Bill Cox О©╫О©╫О©╫О©╫О©╫:
Bill, this is a great idea! An installer of all kinds of shared
libraries, instead of Qt-specific Ministro. This calls for creation of
some kind of organization of Android developers, some "Free Android
Native Library Foundation" which will maintain common repository of
shared libraries and the installer.
Something like that is necessary even for future of Ministro in its
current role. There must be some open and trustworthy organization which
would support Qt/Android port, take necessary actions to ensure
compatibility with existing apps and release new versions of libraries
fast enough. Also decisions about directions of development must be
taken collectively and according to some accepted strategy. Otherwise,
no serious project can rely on Ministro. I wish Nokia or Google could do
that, but they keep quiet although I am sure they are watching us now.
--
Best regards,
Sergey A.Galin
Bill Cox
> Hi Folks,
>
> Пт., 04/03/2011 в 04:51 -0800, Bill Cox пишет:
Sounds like you're very interested in making it happen. I'm
definitely for it. I'm afraid I really am a newbie here, though I've
done a bit of QT programming, and a bit of Debian packaging. If you
do form an Android Native Library Foundation, I'd be interested in
contributing.
Here's just my $0.02 cents worth of dumb ideas to consider when
forming this thing. Debian is the largest collection of free software
libraries, and it is outstanding, but IMO, it's now falling behind,
and even introducing red tape. If I want to publish an Android app,
it's no big deal. Google checks it a bit and generally approves it
quickly. I've got a library I've been trying to get into Debian since
November, but it hasn't even been reviewed yet. And by the way,
packaging for Debian is no small task, and it took me a week.
Assuming it finds a sponsor and passes review, it will become part of
Debian Unstable. However, no one is willing to have their application
depend on my library until it's available in the same version as their
application, so older popular apps that are already in Debian Stable
wont be able to use my work for years. In short, we've created
tremendous red tape in the open-source community, and it greatly
hampers the pace of innovation and progress.
I think with Android, we might be able to improve the situation.
Publishing an open-source library should be as easy as creating a git
repository on github.net. I think we could eliminate the review
process, if we are clever about it. For example, we could use the
web-of-trust idea to rate author's trust worthiness, and we could
recommend libraries we trust and find useful. As a library enters
popular usage and becomes stable, it's trustworthiness score could
increase. Users should be fully aware of the trust level when
installing a library.
Another major headache is library version dependencies. I still have
various apps break when I "apt-get upgrade". It's just not possible
eliminate bugs caused when libraries are upgraded. The one strong
point behind Android's approach of shipping every dependency in every
app is it eliminates these bugs. As an example, I have a significant
accessibility bug fix I did for GTK+ last spring. However, everyone
is so scared of changing core stuff in GTK, the fix will probably
never be adopted. There's simply too much potential damage in
upgrading a library like GTK+, because so many applications depend on
it. If the fix ever does make it in, it will be several ye ars before
it's in any stable Debian release. So, here's a dumb idea for dealing
with this. Do like Android does, and require the exact binary
libraries be installed that were there when the app was compiled.
However, share libraries between apps, so multiple apps using the
exact same library can share the binary file. I suspect that for QT
apps could do a ton of sharing that way. While having multiple
versions of libraries installed at the same time will waste space,
lets not get too freaked out about it. I have 32 gigabytes on my SD
card, and even with Android app bloat, apps barely make a dent.
Simply requiring the exact binaries be present tremendously simplifies
packaging and greatly increases robustness. Ministro could keep track
of dependencies, and when an app upgrades and no longer needs an older
library version, it could be deleted automatically.
Another issue is sharing Java .jar files on Android. I don't know how
or even if it could be done, but we should be able to install .jar
files we depend on in a similar manner to installing shared .so files.
I really do think this is a huge issue. We currently have to share by
copying source code into our apps. The pain threshold is way to high,
and as a result, little free software (aka open-source) is making it's
way onto Android. Sharing libraries is the primary way programmers
cooperate. I think we need it big-time for Android if we want to
increase the pace of innovation.
Bill
Ross Bencina
>Another major headache is library version dependencies. I still have
>various apps break when I "apt-get upgrade". It's just not possible
>eliminate bugs caused when libraries are upgraded. The one strong
>point behind Android's approach of shipping every dependency in every
>app is it eliminates these bugs.
I agree with this. For Qt I think it is worse than with some other libraries
though -- there are so few patch releases that "major" (imho) bugs often
persist until the next point release. Perhaps this will change with open
governance, not sure.
With Qt on desktop systems I have never (since 2009) used a non-privately
patched version of Qt. There have always been bugs/regressions that I had to
patch in Qt to ship high quality build of my app. I suspect the same
situation will exist in Android./Ministro because that is the nature of Qt
so far.
Personally I hope for better non-Ministro in-app bundling support in
Neccessitas since QA(app+Qt) is not the same as QA(app)+QA(Qt). Nothing
against Ministro of course, just that I don't think the approach suits all
uses.
Best wishes
Ross
Bill Cox
What if Ministro (or whatever the packaging system becomes) allowed
your app to easily use all the exact binaries you used in testing,
including your modified QT binaries as well as stock versions you
didn't touch? What if you could publish your modified version in 5
minutes to make it available to anyone else who wants it, and what if
a patch file were auto-generated and e-mailed upstream to the QT
maintainers? Today, we spend a ridiculous amount of time testing
formatting and lobbying for our bug fixes to be included upstream, but
like the QT guys, many up-stream teams are insanely slow to adopt
patches.
Ross Bencina
>What if Ministro (or whatever the packaging system becomes) allowed
>your app to easily use all the exact binaries you used in testing,
>including your modified QT binaries as well as stock versions you
>didn't touch? What if you could publish your modified version in 5
>minutes to make it available to anyone else who wants it, and what if
>a patch file were auto-generated and e-mailed upstream to the QT
>maintainers? Today, we spend a ridiculous amount of time testing
>formatting and lobbying for our bug fixes to be included upstream, but
>like the QT guys, many up-stream teams are insanely slow to adopt
>patches.
That's a great idea. If users download custom Qt builds as small binary
patches against "official" Ministro binaries it would be a significant win
in time and bandwidth, even if the custom binaries used just as much space
on the target device.
Ross.