Your message dated Tue, 3 Jan 2017 15:53:34 +0000
with message-id <[email protected]>
and subject line Re: Bug#850039: flatpak dependency problems
has caused the Debian Bug report #850039,
regarding flatpak dependency problems
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
850039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850039
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: flatpak
Version: 0.8.0-1
Severity: important

Hello,

Thanks for packaging flatpak at its latest.

I've tried exploring flatpak, as a means to install proprietary software
that I sometimes use. In that quest, I started with flatpak upstream's
instrcutions at: http://flatpak.org/apps.html

My interest is in trying out Skype.

When trying to install it on Debian, I get:

rrs@learner:/tmp$ flatpak install --from
https://s3.amazonaws.com/alexlarsson/skype-repo/skype.flatpakref
Installing: com.skype.Client/x86_64/alpha
Required runtime for com.skype.Client/x86_64/alpha
(org.freedesktop.Platform/x86_64/1.4) is not installed, searching...
The required runtime org.freedesktop.Platform/x86_64/1.4 was not found
in a configured remote.
error: The Application com.skype.Client/x86_64/alpha requires the
runtime org.freedesktop.Platform/x86_64/1.4 which is not installed
2017-01-03 / 18:26:50 ♒♒♒  ☹  => 1  


Which doesn't give any hint on what needs to be done. In traditional
package managers, I'd do a search for the missing pacakge. In this case,
I'm left clueless.

I looked for a Debian specific README, assuming there may be any Debian
specifc quirk, but did not find any such document.



rrs@learner:/tmp$ flatpak remote-list
com.skype.Client-origin
2017-01-03 / 18:37:21 ♒♒♒  ☺  


This doesn't give much pointers.


rrs@learner:/tmp$ flatpak remote-ls
Usage:
  flatpak remote-ls [OPTION...]  REMOTE - Show available runtimes and 
applications

Help Options:
  -h, --help             Show help options

Application Options:
  --user                 Work on user installations
  --system               Work on system-wide installations (default)
  --installation         Work on a specific system-wide installation
  -d, --show-details     Show arches and branches
  --runtime              Show only runtimes
  --app                  Show only apps
  --updates              Show only those where updates are available
  --arch=ARCH            Limit to this arch (* for all)
  -v, --verbose          Print debug information during command processing
  --ostree-verbose       Print OSTree debug information during command 
processing

error: REMOTE must be specified
2017-01-03 / 18:37:24 ♒♒♒  ☹  => 1  


This seems better. But what remote ? Should this remote be listed
somewhere ? Is it a global independent remote ? Or a Debian specific
remote ?

PS: In the problem space that these tools are trying to solve, in my
opinion AppImage is the simplest one, which is self-contained and does
not have any dependency solving.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0+ (SMP w/4 CPU cores)
Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flatpak depends on:
ii  bubblewrap             0.1.5-1
ii  fuse                   2.9.7-1
ii  libarchive13           3.2.1-5
ii  libc6                  2.24-8
ii  libfuse2               2.9.7-1
ii  libglib2.0-0           2.50.2-2
ii  libjson-glib-1.0-0     1.2.2-1
ii  libostree-1-1          2016.15-2
ii  libpolkit-gobject-1-0  0.105-17
ii  libseccomp2            2.3.1-2.1
ii  libsoup2.4-1           2.56.0-2
ii  libxau6                1:1.0.8-1

Versions of packages flatpak recommends:
ii  desktop-file-utils     0.23-1
ii  gtk-update-icon-cache  3.22.5-1
ii  hicolor-icon-theme     0.15-1
ii  libpam-systemd         232-8
ii  shared-mime-info       1.7-1

flatpak suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
On Tue, 03 Jan 2017 at 18:43:33 +0530, Ritesh Raj Sarraf wrote:
> rrs@learner:/tmp$ flatpak install --from
> https://s3.amazonaws.com/alexlarsson/skype-repo/skype.flatpakref
> Installing: com.skype.Client/x86_64/alpha
> Required runtime for com.skype.Client/x86_64/alpha
> (org.freedesktop.Platform/x86_64/1.4) is not installed, searching...
> The required runtime org.freedesktop.Platform/x86_64/1.4 was not found
> in a configured remote.
> error: The Application com.skype.Client/x86_64/alpha requires the
> runtime org.freedesktop.Platform/x86_64/1.4 which is not installed

There does not seem to be a bug here. I agree that it isn't obvious what
you should do next, but that isn't something we are likely to be able
to solve in a Debian-specific way.

What you need here is to add a "remote" (analogous to a git remote or an
apt repository) that provides the org.freedesktop.Platform/x86_64/1.4
runtime. org.freedesktop.Platform is one of the runtimes provided in
the "gnome" repository that is documented in <http://flatpak.org/#users>.

Recent Flatpak versions have a way for a .flatpakref to offer to set up
an appropriate remote for the dependencies if they aren't already
available, but
https://s3.amazonaws.com/alexlarsson/skype-repo/skype.flatpakref
doesn't appear to do so. I would advise talking to its publisher,
presumably Alex Larsson (who is also the main author of Flatpak and
the publisher of the GNOME and freedesktop.org runtimes).

The higher-level tools around Flatpak are not particularly mature at
the moment, but I believe the intention is that the majority of
interactions with Flatpak should happen via GNOME Software (or an
analogous user interface in non-GNOME environments) rather than via
the CLI tools. GNOME Software uses a plugin linked to the same
libraries as flatpak(1).

> This seems better. But what remote ? Should this remote be listed
> somewhere ? Is it a global independent remote ? Or a Debian specific
> remote ?

It is not Debian-specific. Please see <http://flatpak.org/#users>.

Flatpak can be used with runtimes and remotes provided by anyone, but
the example/reference source of runtimes is the "gnome" repository/remote
described on that page, which provides both freedesktop.org runtimes
(a base environment) and GNOME runtimes (the freedesktop.org runtimes
plus additional higher-level libraries from GNOME). Other vendors
such as KDE provide their own runtimes, either based on the reference
freedesktop.org runtimes or independently constructed.

At some point I'm hoping to publish Debian-based runtimes (basically
the result of debootstrap and some apt/dpkg operations) that offer
an alternative base; but it is the publisher of an app, not the user,
that chooses what the supported runtime is for an app.

> PS: In the problem space that these tools are trying to solve, in my
> opinion AppImage is the simplest one, which is self-contained and does
> not have any dependency solving.

AppImage is self-contained, except for when it isn't. My understanding
is that a typical AppImage assumes some libraries from the host system,
but has no way to express that dependency in metadata, similar to the
situation traditionally seen for executable installers for proprietary
software.

AppImage is certainly simpler than Flatpak, because it has neither
the runtime concept (security updates for common libraries, orthogonal
to updating the app) nor sandboxing (the third-party software is
treated as fully trusted, again similar to traditional executable
installers). There is no perfect solution here, only trade-offs.

I personally think a combination of either OSTree or apt for a
base system, Flatpak for high-level apps, and a Debian-derived
Flatpak runtime built from dpkg/apt packages has a lot of potential:
that's the model used in Endless, for example. However, there's no
reason Flatpak, Snap and AppImage can't coexist on the same system.

    S

--- End Message ---
_______________________________________________
Pkg-utopia-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

Reply via email to