4 ms·

> packaging a deb is difficult. I've done it, and it's a lot of complicated hard work you get to repeat for every release for anything that is not a simple prog

by gspr 7y ago

> packaging a deb is difficult. I've done it, and it's a lot of complicated hard work you get to repeat for every release for anything that is not a simple program Right, but the point of a high-quality distribution is that this complicated hard work only needs to be done once (per package, updated for upstream changes obviously) by your distribution's package maintainer. Then it scales for free. That's the beauty.

rlpb 7y ago
Snaps solve the problems caused by users installing from third party apt repositories. Users do that today. Comparing against the virtues of distribution-provided packages is a strawman. The exception is distribution packages like Chromium and Firefox. These don't work well in deb format, because users expect the latest upstream updates after the distribution releases, but upstreams add dependencies creating dependency hell for packagers. Snaps work better for this case.
fulafel 7y ago
Deveroper/packager productivity matters a lot, as people will then bother to package more nice things and keep those packages up to date. It's bad for everyone if packaging is needlessly hard. Also the sw engineering world is clearly moving away from packaging as "integate application into distro X version set of library versions by continuously expending a lot of integration engineering effort" and more towards things like docker images, snap/flatpak/appimage that sidestep the problem of host platform component dependencies as much as possible.
ric2b 7y ago
But your distribution's package maintainer has limited bandwidth, there's only so much software they can support. At some point you need a way for developers to do it themselves.
BiteCode_dev 7y ago
> Right, but the point of a high-quality distribution is that this complicated hard work only needs to be done once (per package, updated for upstream changes obviously) by your distribution's package maintainer. Sure it works for a sysadmin, but it's not matching at all how regular people are using their computer. It means you can only use packages that are part of the official repo and: - it's hard to get in those official repo - it takes a lot of time - it assumes free software - if your app embeds its own dependancies, it's usually rejected by default - it's a bottleneck for publication (the repo team is limited in resources) - you have no control over updates - you can't make people pay for software that are in those repos - you may want/need to package the software yourself or for yourself On my computer I have a huge number of softwares that I have not installed from the repos: puslsms, vscode, telegram, dynalist, veracrypt, signal, discord, antidote, bitwarden firefox developper, guitar, stremio, pop corn time, dukto, photoflare, sublime text, table plus and sublime merge I think using the simple act of spreading this argument is a demonstration of how remote one can get from the vast diversity of the user base.

by gspr 7y ago

rlpb 7y ago

Snaps solve the problems caused by users installing from third party apt repositories. Users do that today. Comparing against the virtues of distribution-provided packages is a strawman. The exception is distribution packages like Chromium and Firefox. These don't work well in deb format, because users expect the latest upstream updates after the distribution releases, but upstreams add dependencies creating dependency hell for packagers. Snaps work better for this case.

fulafel 7y ago

Deveroper/packager productivity matters a lot, as people will then bother to package more nice things and keep those packages up to date. It's bad for everyone if packaging is needlessly hard. Also the sw engineering world is clearly moving away from packaging as "integate application into distro X version set of library versions by continuously expending a lot of integration engineering effort" and more towards things like docker images, snap/flatpak/appimage that sidestep the problem of host platform component dependencies as much as possible.

ric2b 7y ago

But your distribution's package maintainer has limited bandwidth, there's only so much software they can support. At some point you need a way for developers to do it themselves.

BiteCode_dev 7y ago

> Right, but the point of a high-quality distribution is that this complicated hard work only needs to be done once (per package, updated for upstream changes obviously) by your distribution's package maintainer. Sure it works for a sysadmin, but it's not matching at all how regular people are using their computer. It means you can only use packages that are part of the official repo and: - it's hard to get in those official repo - it takes a lot of time - it assumes free software - if your app embeds its own dependancies, it's usually rejected by default - it's a bottleneck for publication (the repo team is limited in resources) - you have no control over updates - you can't make people pay for software that are in those repos - you may want/need to package the software yourself or for yourself On my computer I have a huge number of softwares that I have not installed from the repos: puslsms, vscode, telegram, dynalist, veracrypt, signal, discord, antidote, bitwarden firefox developper, guitar, stremio, pop corn time, dukto, photoflare, sublime text, table plus and sublime merge I think using the simple act of spreading this argument is a demonstration of how remote one can get from the vast diversity of the user base.