On Sat, 2019-08-10 at 21:02 +0000, aberba via Digitalmars-d wrote: […]
> The future of Linux app distribution is either Flatpak (https://flatpak.org/) or Snap (https://snapcraft.io/). Among which Flatpak is technically more powerful/promising.
[…]

So instead of a Deb vs. RPM war we now have a Snap vs. Flatpak was. As ever this remains a RedHat vs. Canonical war.

Is it clear that either Snap or Flatpak are as efficient as native packages in terms of space requirements, download time, install time.

Currently, I use Linuxbrew for the very few packages I cannot get from the Debian repository. I'd like to avoid Snap or Flatpak if at all possible.

Does AppImage have a role? Or one of the other tens of "solutions" to the "we have to have a single packaging system for all Linux distributions" "problem".


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 11 August 2019 at 11:40:18 UTC, Russel Winder wrote:
> Is it clear that either Snap or Flatpak are as efficient as native packages in terms of space requirements, download time, install time.

As a point of comparison, the ldc2 snap package is about 70 MB on disk.  The deb packages covering equivalent functionality would be:

  * ldc (14.2 MB)
  * libllvm5.0 (13.7 MB)
  * libphobos2-ldc-shared78 (8 MB)
  * libphobos2-ldc-shared-dev (56.7 MB)

... so if anything the snap package takes up slightly less space (with a difference being that of course the LLVM components it incorporates are for its own use only, not a shared library usable by the rest of the system).

Probably the major differentiator here is that snap packages use squashfs for storage, so the "true" size of the package is larger than the actual disk usage.  I think uncompressed the snap package would be about 290 MB, most of which is the compiler itself (66 MB) plus libraries (52 MB for 32-bit, 145 MB for 64-bit).

Bear in mind that the snap package includes both 32- and 64-bit libs, in versions with and without debug symbols, whereas the deb packages only include 64-bit.  The snap package also includes LTO support (which accounts for about 45 MB of the total uncompressed lib size).

Bottom line, the snap package gives you a greater amount of functionality while using a smaller amount of actual disk space (thanks to squashfs).  And if we looked carefully at what is being included, it might be possible to reduce the size further.

On Sun, 2019-08-11 at 12:41 +0000, Joseph Rushton Wakeling via Digitalmars-d
wrote:
[…]

Hi,

Thanks for the email, very interesting, and lowers the bar for me to use snaps.

Whilst the Debian package is 1.12.0, and the snap is 1.14.0, both are fairly old. I guess the Debian freeze stopped upgrade in Debian Sid, and I guess it requiring volunteers is stopping both the Debian package and the snap being updated.

The Linuxbrew formula is 1.16.0 but it requires rebuild of some very big packages that are not bottled.

I will continue to prioritise Debian packages, but I have now added snaps to Linuxbrew for specific packages that Debian doesn't provide to the required level. As to whether to snap or brew, I am not yet sure what to get from which.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 12 August 2019 at 11:53:14 UTC, Russel Winder wrote:
> Whilst the Debian package is 1.12.0, and the snap is 1.14.0, both are fairly old. I guess the Debian freeze stopped upgrade in Debian Sid, and I guess it requiring volunteers is stopping both the Debian package and the snap being updated.

I'm the maintainer of the snap package, and I'm afraid the outdatedness is entirely my fault (the day job is very busy right now, and I've got behind).  But you can already install 1.16.0 by using the 'edge' channel (for the latest packages):

    sudo snap install --classic --edge ldc2

The main reason for lack of progress here is not creating a package for the new version, but making sure it gets at least minimal tests across the range of different install targets.

In any case I'm happy to hear that the snaps might be useful for you.  I'll try to put some time this weekend to testing to make sure I can get the 1.16.0 release out soon (and 1.17.0 as soon as that is released).

There are also snap packages for dmd and dub (which I also maintain), and a number of other tools (including dscanner, dfmt, and drepl) which are maintained by Ernesto Castellotti.

On Saturday, 10 August 2019 at 08:32:05 UTC, Russel Winder wrote:
> On Fri, 2019-08-09 at 16:58 +0000, BoQsc via Digitalmars-d wrote:
>> 
> […]
>> I'd prefer having D language compiler included into next releases
>> of Linux distributions.
>> I'm worried that https://d-apt.sourceforge.io/ repository's
>> package nor D language compiler's license is compatible to be
>> included and even preinstalled in Distributions such as Ubuntu.
>
> Clearly it would be better if dmd, dcd, dfmt, dfix, dscanner, dub etc. were all in the standard Debian repository along with ldc, gdc, gtkd, gstreamerd, tilix, etc.
>

Archlinux has done this, and is always keeping updated(except gdc), :)

```
$ pacman -Ss dlang
community/dcd 1:0.12.0-1 (dlang) [installed: 1:0.11.1-1]
    D Completion Daemon: auto-complete for the D programming language
community/dfmt 0.10.1-1 (dlang) [installed]
    Dfmt is a formatter for D source code
community/dmd 1:2.087.1-1 (dlang dlang-dmd) [installed: 1:2.087.0-1]
    The D programming language reference compiler
community/dmd-docs 1:2.087.1-1 (dlang dlang-dmd) [installed: 1:2.087.0-1]
    Documentation and sample code for D programming language
community/dscanner 0.8.0-1 (dlang) [installed: 0.7.2-1]
    Swiss-army knife for D source code
community/dtools 2.087.1-1 (dlang) [installed: 2.087.0-1]
    Ancilliary tools for the D programming language
community/dub 1.16.0-1 (dlang) [installed]
    Developer package manager for D programming language
community/gdc 8.2.1+2.068.2-2 (dlang)
    Compiler for D programming language which uses gcc backend
community/ldc 2:1.16.0-2 (dlang dlang-ldc) [installed]
    A D Compiler based on the LLVM Compiler Infrastructure including D runtime and libphobos2
community/libgphobos 8.2.1+2.068.2-2 (dlang)
    Standard library for D programming language, GDC port
community/liblphobos 2:1.16.0-2 (dlang dlang-ldc) [installed]
    A D Compiler based on the LLVM Compiler Infrastructure including D runtime and libphobos2
community/libphobos 1:2.087.1-1 (dlang dlang-dmd) [installed: 1:2.087.0-1]
    The Phobos standard library for D programming language

```