3 ms·

Isn't ubuntu snap already doing all this? The competing standards I don't think help in this regard. Now to make a "portable service" I will need to make sure w

Isn't ubuntu snap already doing all this? The competing standards I don't think help in this regard. Now to make a "portable service" I will need to make sure whatever I do can be used as a snap and a systemd portable service. Why is it so hard to settle on a standard when it comes to this stuff? The same confusion exists when it comes to rpm and deb packaging formats. At the end of the day both do the same thing and yet to deliver software to redhat and debian systems you have to double your packaging effort.

mateuszf 10y ago
Because systemd is more popular and cross distros.
derefr 10y ago
The RPM/Deb split, at this point, isn't so much about packaging formats, as it is about dependency graphs. Even if the two distro "families" of Redhat and Debian shared a common packaging format, a package would still have to be built—or at least specified—twice for them, because each family would still have its own set of deps that are factored out in incompatible ways to the deps of the other family. (For example, in Debian land, if your package wants to declare a dependency on OpenSSL, that might mean a package dependency on any of 'openssl', 'libssl1.0.0', 'libssl1.0.0-dbg', or 'libssl-dev'. RHEL et al do not have an isomorphic set of packages that these dependencies could be mapped to.)
- vbernat 10y ago
  This is already the case for SuSE and Redhat. Package names are different, RPM macros are different. Doing a package that works for both is gruesome. Also, at the time of SysV, you had to use two different init scripts.
wmf 10y ago
Presumably portable services will work on Ubuntu so you could skip the snap. There will never be agreement on standards that are used as strategic weapons in developer mindshare turf wars between companies using monopoly-or-die-trying business models.
niemeyer 10y ago
Such competing efforts are actually a form of non-voluntary collaboration. rpm and deb (and apt, yum, synaptic, ...) have significantly evolved together along the years, looking at each other. This happens all the time, and is happening again here.. the snap format and snapd evolve based on previous knowledge, and it's no surprise that the linked LWN article seems quite inspired by snaps (I'm biased as a snapd designer/developer). Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.

mateuszf 10y ago

Because systemd is more popular and cross distros.

derefr 10y ago

The RPM/Deb split, at this point, isn't so much about packaging formats, as it is about dependency graphs. Even if the two distro "families" of Redhat and Debian shared a common packaging format, a package would still have to be built—or at least specified—twice for them, because each family would still have its own set of deps that are factored out in incompatible ways to the deps of the other family. (For example, in Debian land, if your package wants to declare a dependency on OpenSSL, that might mean a package dependency on any of 'openssl', 'libssl1.0.0', 'libssl1.0.0-dbg', or 'libssl-dev'. RHEL et al do not have an isomorphic set of packages that these dependencies could be mapped to.)

vbernat 10y ago
This is already the case for SuSE and Redhat. Package names are different, RPM macros are different. Doing a package that works for both is gruesome. Also, at the time of SysV, you had to use two different init scripts.

wmf 10y ago

Presumably portable services will work on Ubuntu so you could skip the snap. There will never be agreement on standards that are used as strategic weapons in developer mindshare turf wars between companies using monopoly-or-die-trying business models.

niemeyer 10y ago

Such competing efforts are actually a form of non-voluntary collaboration. rpm and deb (and apt, yum, synaptic, ...) have significantly evolved together along the years, looking at each other. This happens all the time, and is happening again here.. the snap format and snapd evolve based on previous knowledge, and it's no surprise that the linked LWN article seems quite inspired by snaps (I'm biased as a snapd designer/developer). Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.