Batis - XDG-based packaging for Linux desktop apps

[Matthias Klumpp]

2015-11-21 18:14 GMT+01:00 Thomas Kluyver <thomas at kluyver.me.uk>:
> On Sat, Nov 21, 2015, at 03:58 PM, Shaun McCance wrote:
>> I think you're confusing understanding how a system works underneath
>> with understanding how to use it. GitHub is a testament to the massive
>> number of people who use git. A very small handful of those people
>> really truly grok how git works under the hood.
>
> I'm not confusing those things, but I think it's important that
> developers can understand what's going on as well as how to use the
> tools. This is a complex topic - clearly there's a lot of stuff we use
> every day without really understanding - but broadly I'm not comfortable
> with saying "don't worry about how this works, just use it". People use
> git, but they're not exactly happy about its incomprehensible nature
> (https://xkcd.com/1597/ ;-). One of my aims with Batis was precisely to
> keep it easy to understand, not just easy to use.

Hi there!
I'm the developer of Limba, a software distribution system based on
OverlayFS with a few conceptual differences to xdg-app[1].
First of all, great that you're interested in the topic of making
software distribution on Linux easier.
I suppose you have looked at existing solutions to the problem, like
0install, Limba and XdgApp. What is the thing which makes your project
special compared to those (there must be some unique selling point,
right?)?
I didn't look a Batis very closely yet, but I have a few questions:

 * It looks like Batis allows apps to depend on distributor-provided
software - how do you handle missing dependencies of your software?
How do you plan to handle binary incompatibilities?

 * Batis allows scripts to be run at install time - how do you want to
secure your installation processes, and adapt the newly installed apps
to the system they are running on? IMHO and automatic configuration or
a declarative interface would be much better than to allow the
execution of arbitrary scripts at install-time.

Limba originates from previous projects, some of which were already
written in 2007/2008. XdgApp also had it's old predecessors, Alex is
working in this field for years as well. What I want to say with that
is, that this issue of software distribution looks very simple at
first, but can become very complex and is much more complicated under
the surface. The current solutions are the result of previous failures
and experience gained.
So, for Batis, if you think developing this as a new solution, by all
means go for it, but also take a look at other projects to see how
they solved issues. That will help you a lot in finding a good
solution (although I would also recommend to take a closer look if you
want to get involved in one of the existing projects, if they fit your
goals - the people working on them are really nice, and like new
contributors!).
I think especially 0install might be interesting for you (but 0install
is not only cross-distro but also cross-platform, so one needs to
account for that when working on it).

2015-11-20 23:58 GMT+01:00 Bastien Nocera <hadess at hadess.net>:
> [...]
> Matthias (from limba) and Alex (xdg-app) seem to be speaking together
> regularly, FWIW.

Yes, and I am very happy about that :-) There are conceptual
differences between XdgApp and Limba in the area of
dependency-handling and building software, but aside from that there
is no need to diverge. We try to share as much code as possible, which
is currently quite simple: XdgApp is spearheading sandboxing, all the
sandbox development is happening there. Limba will later just
implement the same specifications to allow sandboxing in the very same
way XdgApp does.
Also, I added support for both XdgApp and Limba to the AppStream
metadata specification, so we will have them seamlessly integrated
into software centers like GNOME-Software / KDE Discover. Users won't
see the differences, but developers can choose the best way for them
to distribute applications (where apps with rapid development will
likely pick Limba, and apps with a slower release cycle and demands
for a rock-solid runtime will choose XdgApp.- the user doesn't need to
care at all, as long as distributions allow both solutions to be
used).

Cheers,
    Matthias