mon journal - par Vincent - Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Commentsmon journal - par Vincent2023-01-23T10:27:08+00:00Vincent Untzurn:md5:7aa93f65570cd775650ccbcbffddebcfDotclearResults of the App Installer meeting, and some thoughts on cross-distro collaboration - Lestibournesurn:md5:52dc43ec9b8ed6d6081db377f6e375d02011-02-02T20:45:51+01:002011-02-02T20:45:51+01:00Lestibournes<p>Zero Install should support:<br />
1. Servers that require authentication, and multiple or custom authentication schemes defined by the server.<br />
2. Software catalogs that list Zero Install packages, serving as a repository index of sorts.<br />
3. Using alternative but compatible packages so that distros can ship their own patched versions.<br />
4. Creating various update policies.<br />
5. Installing packages system-wide like the traditional package managers.</p>
<p>If all the above is implemented then I think there should be no problem for distros to use Zero Install as their one and only package manager. Even Ubuntu would be able to use it for USC.</p>
<p>I wrote this after reading this article:<br />
<a href="http://www.osnews.com/comments/16956" title="http://www.osnews.com/comments/16956" rel="ugc nofollow">http://www.osnews.com/comments/1695...</a><br />
and I don't think I have any more recent knowledge of Zero Install than that, so my comments may be outdated.</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Tomurn:md5:e47925ddf944e211f1349b786c5b928b2011-02-01T12:22:21+01:002011-02-01T12:22:21+01:00Tom<p>@Vincent (french pronounciation):</p>
<p>Do you think there could be a LSB conforming common package format for .deb- and .rpm-based distros?</p>
<p>Maybe something like .lsb or .up (universal package) would make it much easier to distribute software for Linux. If you can't find the software you want in a repo/app store you will still be pretty much frakked for the foreseeable future.</p>
<p>Maybe after appstream, that is the next big thing that could come out of this.</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - mannyurn:md5:9efb3aeb000cd1ac5e80c7823506e04d2011-01-28T23:36:27+01:002011-01-28T23:36:27+01:00manny<p>@Vincent</p>
<p>if you have a minute, i have a small doubt.<br />
I would like to know how will appstream be different from similar projects, like say zero-install?<br />
<a href="http://zero-install.sourceforge.net/matrix.html" title="http://zero-install.sourceforge.net/matrix.html" rel="ugc nofollow">http://zero-install.sourceforge.net...</a></p>
<p>Since the work is pretty similar, maybe it can give a hint on a few things or maybe the author might want to collaborate, since he's been at it for quite a while.</p>
<p>Anyway, am pretty sure that anything you guys accomplish will be a good step in the right direction.</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - skierpageurn:md5:04f196fdd80901193c71c42a8f1d7f672011-01-28T08:08:34+01:002011-01-28T08:08:34+01:00skierpage<p>Please consider using normal ISO8601 date-time format as the timestamp of comments on your blog.</p>
<pre> [26/01/2011@15:54]</pre>
<p>is ambiguous (is that a month or a day first?) and using @ for the time confuses with everyone writing @Stu and @Vincent.</p>
<pre> 2011-01-26 15:54</pre>
<p>is clear and standard. Cheers (and thanks for promoting cross-distro collaboration!)</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - mannyurn:md5:130c0e447b7e5b6caea6d91147eb89fb2011-01-28T05:45:38+01:002011-01-28T05:45:38+01:00manny<p>this is something commercial game makers have been asking for years (and many others) :)</p>
<p>if done right this could be amazing</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Pascal Bleserurn:md5:2ee588c8874cfc44ee62aad2ef920ffe2011-01-26T15:54:56+01:002011-01-26T15:54:56+01:00Pascal Bleser<p>@<a href="https://www.vuntz.net/journal/post/2011/01/25/Results-of-the-App-Installer-meeting%2C-and-some-thoughts-on-cross-distro-collaboration#c4642" rel="ugc nofollow">Stu</a>: it remains difficult, because package formats are different, and versions of those differ too (i.e. RPM vs deb, RPM 4 vs RPM 5, ...). One of the very few options to do that is the openSUSE Build Service (<a href="http://en.opensuse.org/Portal:Build_Service" title="http://en.opensuse.org/Portal:Build_Service" rel="ugc nofollow">http://en.opensuse.org/Portal:Build...</a>), which is not limited to nor specific to openSUSE, but instead gives the ability to build packages for multiple distributions from a single source (more or less).</p>
<p>And I'm not even sure whether filesystem paths for font files are the same across all Linux distributions.</p>
<p>That being said, a package with fonts is really an extreme example in terms of simplicity as it really only contains "data" files and no binaries at all. Once you add binaries (or, more specifically, shared libraries), it becomes a lot more complex even if, for example, only considering RPM based distributions like openSUSE and Fedora.</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Stuurn:md5:0c1006d859780793c2be965b2f09bba52011-01-26T14:54:13+01:002011-01-26T14:54:13+01:00Stu<p>Forgive me if this happens already: I just saw this article on planet.gnome.org under the "unpackaged font of the week" by Máirín Duffy... it occurs to me that for stuff like this, the contents of the package must be simple enough that there could be a way for these to be packaged for all the important distros at the same time?</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Vincenturn:md5:de88aad795f843204ffcaea69c0f88722011-01-26T13:29:03+01:002011-01-26T13:29:03+01:00Vincent<p>All the examples you're giving here are actually already covered, with the concept of add-on. It might not be mentioned in the wiki page, though. The very short summary is that if you have a Enhances/Supplements, then the UI displays this as an add-on to the application that can get installed. It's already working in the Ubuntu Software Center.</p>
<p>The preferences/affinities topic was also discussed. We discussed this as in "what to recommend to users", and several ideas were raised, like using patterns (not patterns as in package patterns, but to identify which apps are often installed together), or to use zeitgeist.</p>
<p>Don't get me wrong, I do know there is experience to be shared, and I'm sure there are things to learn from the Software Portal :-)</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Pascal Bleserurn:md5:4994cd920da36ccfbe557ca31c1ead9d2011-01-26T13:18:06+01:002011-01-26T13:18:06+01:00Pascal Bleser<p>Yes, there are a few use cases where you need several packages. That is, because the target group of such a "store" is clearly less experienced users (everyone else is probably just fine with zypper/yum/apt/whatever) and, hence, a "complete" and "usable" application for a beginner often needs pulling in optional dependencies.</p>
<ul>
<li>MozillaFirefox + MozillaFirefox-translations</li>
<li>amarok + phonon-backend-xine + phonon-backend-gstreamer</li>
<li>totem + totem-lang + totem-plugin</li>
<li>banshee-1 + banshee-1-backend-gstreamer + banshee-1-extensions-default</li>
</ul>
<p>The trick is really the definition of "application", or, rather a "complete" feature set. While experienced users are fine with picking features/plugins through sub packages with a fine granularity, and actually welcome that, less experienced users most definitely prefer just pulling in e.g. "firefox" and have everything that they typically expect to work to... just work.</p>
<p>Another idea behind the Software Portal is to make heavy use of tagging and categorization, to enable less experienced people to look for e.g. "a web browser", "a video player", "a mail client", and have a list of applications that match such criteria. A single click on the install link triggers a YMP (1-click-install, doesn't exist with all distros: Debian has apt://, but Fedora is heavily opposed to something like that), and reviews, comments and screenshots make it easier for people to pick one or another.</p>
<p>Then there is the problem of "preferences"/"affinities" depending on the environment of the user. Note that this cannot be tackled in a pure web application (which the Software Portal is), as it requires some information from the actual system, but a desktop application would be capable of providing that.<br />
Think of it as REST, the HTTP protocol and what a browser sends as preferred language and content types (typically referred to as "content negotiation"). One striking example would be: prefer KDE or GNOME applications in tags/search results/proposals ?</p>
<p>Anyway, lots of details to think of, and Benjamin Weber and I went through quite a few of those things when we implemented the Software Portal. A few things are actually implemented too, such as diffing repository content in the database to determine application updates, new applications, and applications that were removed. The latter has proven to be really tricky to implement in a way that performs well without specific support from repository metadata, but can provide useful information to a "Software Center" application on the desktop (sort of an "RSS feed" of application/package changes over many repositories).</p>
<p>I hope you noticed by now that there is some experience to be shared...</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Vincenturn:md5:276efbb38df2c41ef569ead30b6063ad2011-01-26T12:18:35+01:002011-01-26T12:18:35+01:00Vincent<p>@<a href="https://www.vuntz.net/journal/post/2011/01/25/Results-of-the-App-Installer-meeting%2C-and-some-thoughts-on-cross-distro-collaboration#c4619" rel="ugc nofollow">Pascal Bleser</a>: the wiki page (<a href="http://distributions.freedesktop.org/wiki/AppStream" title="http://distributions.freedesktop.org/wiki/AppStream" rel="ugc nofollow">http://distributions.freedesktop.or...</a>) has more details on how to contact people. We'll use the distributions mailing list: <a href="http://lists.freedesktop.org/mailman/listinfo/distributions" title="http://lists.freedesktop.org/mailman/listinfo/distributions" rel="ugc nofollow">http://lists.freedesktop.org/mailma...</a></p>
<p>As to the definition of applications: we chose to closely link this to .desktop files. I'm not aware of a case where an application requires n packages (with n > 1), and those packages are not installed because of Requires. Do you have such an example?</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - Pascal Bleserurn:md5:2bd735ccd073a01536bd430d96ab49172011-01-26T11:27:15+01:002011-01-26T11:27:15+01:00Pascal Bleser<p>Is there a mailing-list where subsequent discussions will take place or will it remain a closed shop ?</p>
<p>Also, I believe that the current proposal (from what can be seen on the pages you linked to) misses a critical point that was a key goal in our openSUSE Software Portal implementation: the notion of "applications" (as opposed to packages), where one "application" consists of 1-n (and not 1 and only 1) package. And, unfortunately, that is the most complex part of such a "store", everything else is rather trivial to do (I know it is, we did).</p>Results of the App Installer meeting, and some thoughts on cross-distro collaboration - SiathLinuxurn:md5:1b30f694666b7a19968aa5301f25ddb82011-01-26T02:17:56+01:002011-01-26T02:17:56+01:00SiathLinux<p>Having used both Debian based and Red Hat based distributions, I have always wondered why there wasn't a 'general Linux installer' that that would install onto any distribution of Linux, understanding that I was more of an 'End User' and didn't understand just how different distributions could actually be. I am glad that this meeting went well, I hope in the near future it won't matter which distribution a user chooses - there will be just one type of installer.</p>