[SOLVED] Anyone publishing "snaps" ?

WebReflection · 2016-11-04 17:36:16

This is rather personal curiosity, I'd like to understand how much interest there is behind Canonical-like packages.

I like AUR and use yaourt daily, but I have to admit simply reverting a possible package issue is not always straight forward.

The self-contained and transactional feature, together with the ability to publish in one repository for many distros, seems like a very nice achievement but at the same time, I've been on Arch only a couple of years and published few simple AUR packages so I'd like to know more experts opinion, trend, direction these snaps are taking.

Thanks to anyone chiming in with thoughts or real-world experience (even if it's some sort of early stage).

Apologies if already discussed (searching for "snap" didn't bring me what I was looking for).

Best Regards

Last edited by WebReflection (2016-11-07 15:20:49)

eschwartz · 2016-11-06 05:13:28

https://bbs.archlinux.org/viewtopic.php?id=217561
https://bbs.archlinux.org/viewtopic.php?id=217864
https://bbs.archlinux.org/viewtopic.php?id=213828

Aside: What is the problem with downgrading a package via `pacman -U /path/to/package-1.0-i686.pkg.tar.xz`
Very straightforward, and if you need "moar transactional" there is always btrfs+snapper.

Yes, you can downgrade an AUR package like that... all you need to do is use PKGDEST and save your built packages.

WebReflection · 2016-11-07 10:24:52

Thanks for the reply.

I know how to downgrade and indeed I wrote "it's not always straight forward".
Reasons being: maybe I've cleaned the cache, something I do often specially in those laptops with 32GB in total of eMMC
or maybe there were conflicts during the installation that has been poorly resolved and the whole thing is messed up, like with amd-pro package that forced me to erase the whole distro 'cause nothing was working anymore as expected even after manual cleaning up (let's say it took less to reinstall everything).

I believe snaps should make even experimental install somehow easier to handle, if published and compatible as transactional.

Although, following your links, I don't quite find the answer I was hoping for and I'll try to summarize it in here:
is the trend or the long term plan to move to snaps or nobody in Arch cares about snaps so that snaps are once again proving the xkcd stripe?
https://xkcd.com/927/

Last edited by WebReflection (2016-11-07 10:25:44)

Trilby · 2016-11-07 12:07:51

WebReflection wrote:

is the trend or the long term plan to move to snaps or nobody in Arch cares about snaps so that snaps are once again proving the xkcd stripe?

To the degree to which I can speak for arch devs (which is really zero, but hey I'll give it a shot anyways) there is no trend or long term plan for snaps - neither for nor against - they are simply not relevant from a packager/distro-dev point of view for reasons well elaborated on the above-linked threads.

Whether "nobody in Arch cares about snaps" is another question. The fact that it comes up on the forums periodically means people care. But again from the above-linked threads, most passionate responses to the concept of snaps are passionately opposed. So the active forum community (which is certainly a biased subset of the arch community) seems to have a blend of apathy/opposition to snaps.

But then as also noted in one of the above linked threads: flatpak is in [extra]. If you want to use flatpaks, snaps, or anything else, there is nothing stopping you, you will even find some of the tools you need to do so in our main repositories, and others in the AUR. Arch is a DIY distro: you have the power and freedom to make it what you want. Does it really matter to you whether a substantial portion of other archers would also build a similar system to the one you build? As long as you can do what you want, of what consequnce are the trends or long term plans of others?

Trends and long term plans of others matter much more on other distros where distro users get what is given to them and have very little flexibility to customize their system or make it their own. Case in point, I find it baffling that - at least several versions ago - Ubuntu was known for that crazy rusty orange theme. It was just the default theme, but many Ubuntu users seemed to think that that's all they get, so that's what they kept. So when a monitor was covered in a puke orange color, many would just assume "Oh, it's ubuntu". No one will ever look at the colors on a monitor and say "Oh, it's arch linux".

Awebb · 2016-11-07 12:20:49

I don't really want upstream packaged software. There is a reason we started to use the current distro model at some point. Arch is flexible enough to support those container type packages you are talking about. Those packages are also flexible enough to be treated like any binary release in a PKGBUILD. I wouldn't mind using a distro, that is built around that kind of packaging, I just don't want to see more confusion being introduced into Arch.

WebReflection · 2016-11-07 13:43:14

Fair enough and your answers make sense. Although I am not talking as user only, I am talking as developer who needs to provide a random Bash file to have cross platform portability and installability, manually handling different architectures, something AUR does pretty well but AFAIK other distros don't usually access/use AUR to install software so it fails short as universal package manager, right?

Or better, how would you publish some software to as many Linux distro as possible?

I've found myself falling back to third parts repositories like `npm`, a link to x-platform distribution, but that forces me to depend on nodejs which doesn't come for free, specially in ARM / MIPS land.

Gems, pip, or other language dependent package managers would have similar requirement and fragmentation but does it have to be this way?

Thanks again for answers and thoughts.

Trilby · 2016-11-07 13:53:59

WebReflection wrote:

how would you publish some software to as many Linux distro as possible?

Provide the source code. That's it. Leave packaging for a distro in the hands of the people who know packaing for that distro best: it's users and/or developers/packagers. I know this sounds simplistic, but this really is the only sane approach. I've developed software that I've really wanted to be easily usable in other distros. I knew my target audience might not be able to compile software even with just a simple `make && make install`. I really wanted to make .deb and .rpm packages available on my website. You can probably find a thread or two where I was seeking help to do just this. But in the end it was just the wrong approach.

Publish the source code, and be responsive to feedback (pull requests, etc). There is no way for me to keep track of every library version in every distro, but what I can do is listen to users of other distros. I have one package that works great on arch, but it failed miserably on the *buntus because they had a much older version of glib which still required some long-deprecated init function to be run. As soon as a *buntu user pointed it out, I threw in a conditional compile block testing the lib version and added the one needed line of code. It took all of 5 minutes.

Build software that works with upstream stable versions of other software. Be responsive to users who's distros don't work with upstream stable versions of other software.

WebReflection wrote:

I [need] to provide a random Bash file to have cross platform portability and installability

Er, what? Bash is bash. Have you really had issues with portability of a bash script across linux distros? Or do you mean you have a homemade hack to find bad work arounds to problems that have been solved by things like autotools? Portability of code across platforms is very very rarely a real problem if the code was written well in the first place. The differences are only in how that code is compiled and stuffed into binary packages on different distros.

If you mean for scripts, just properly specify your interpreter. Do not use ambiguous shebangs like "#!/bin/python" as you have no idea which python is the default on the end user's system. Specify the proper interpreter, and list it as a dependency in your documentation. But this too is not a cross platform portability issue, it's just good practice.

WebReflection · 2016-11-07 14:11:38

I give you an example, it's echomd, which is open source and uses Bash to self install itself.

curl -o- https://webreflection.github.io/echomd/install | bash

which is what I meant when I've said I need bash. Now, this approach works well, it's a copy and paste procedure that is also quite common in Mac/PC land ... BUT ... it doesn't come with automatic updates and or checks through repositories, so it's kinda a rotten-prone approach, unless it comes with some made-up logic to verify from a repo current and remote version.

Possible, of course, but using AUR as well as any other package manager distro (brew, snaps, whatever) gives me, as software developer, a great way to help users and simplify my own software lifecycle.

Is this really the way to go? I took `echomd` as example because the installer uses x-platform Bash and the application uses Perl which is also natively available, but if I have to read stats and let users decide, its consolemd counter-version based on JS and distributed via `npm` had slightly better feedback.

Does it really have to be this way and for every Open Source software developers create these days? I do the test in all major distros, I use proper way to point at bash, python, or perl, or whatever for my binaries~like files, but wouldn't be great if I could also reach with a single command many distros at once, through a common repository?

Is publishing to all major distros the way? I might create an automation to do that too ... it just feels a bit redundant overall.

Thanks for thoughts or hints.

Trilby · 2016-11-07 14:29:14

Oh dear god. Does anyone actually run that command? You want people to curl some random content and execute it in a root bash session (which itself then curls some other content)? And you assume sudo is present if they are not running as root? All this just so you can share a single-file perl script? You also assume that bash is present, even though nothing in what you are distributing (the perl script) actually needs bash.

Do not reinvent the wheel, and if you do, don't make it a triangle.

Distribute your perl script. If you want, throw in a Makefile with a proper install directive. That's it.

Snaps or flatpaks would not help with this in the slightest.

WebReflection · 2016-11-07 14:44:41

Oh dear god. Does anyone actually run that command?

that's how many more or less famous projects get usually installed, copy and pasting some line in the terminal (terminal runs usually in bash so yes, bash is present there) so I've done everything but reinventing a wheel.

Nvm, Brew itself, just examples of copy and paste line in terminal with one-off need for super user power.

Anyway, the perl script is there already: https://github.com/WebReflection/echomd … erl/echomd while a Makefile command isn't that user friendly: it requires that you have github, you clone the repo, you have make available as dev tool ... nothing like this is needed with the current procedure and as you can see you can also just

yaourt -S echomd

which is exactly why I am here asking if using snaps would be a better way to distribute, with one line of code, Open Source software.

It avoids many "oh dear god" reactions, it ensure better dependencies, lifecycle, and updates done in the natural way a package manager would grant.

After reading your last comment to the most basic example that came to my mind I understand you are not for user-land simplicity while I believe copy and paste is still what most people do and appreciate if it means avoiding extra steps.

I also hope this won't turn out as a thread for echomd installer which does the job and has no side effects beside eventually failing to move a file.

Last edited by WebReflection (2016-11-07 14:46:16)

Scimmia · 2016-11-07 14:50:27

And now yaourt has been recommended. This is quickly becoming hopeless.

I'll say this straight out, bundling deps with a program is a horrible, horrible idea that will lead to Windows level security issues.

WebReflection · 2016-11-07 14:56:14

And now yaourt has been recommended. This is quickly becoming hopeless.

What do you mean?

bundling deps with a program is a horrible, horrible idea

Isn't that what AUR packages do as well? (not the bundling, having dependencies)
What are you referring to?

Are you saying AUR isn't a good channel to distribute Open Source software? Or it's about the usage of

yaourt

in particular?

Last edited by WebReflection (2016-11-07 14:57:11)

Scimmia · 2016-11-07 14:58:58

Dependencies and bundling are to very, very different things.

WebReflection · 2016-11-07 14:59:45

Who said the word bundling before you? What are you talking about?

Last edited by WebReflection (2016-11-07 15:00:09)

Lone_Wolf · 2016-11-07 15:02:10

snaps and flatpaks both bundle dependecies with programs .

WebReflection · 2016-11-07 15:07:54

didn't know that ... every single time? it's a share-nothing, Docker/vagrant like approach so that my `echomd` would include some perl dll in it?

This might already answer most of my questions, I thought there was a smarter new way to grant snaps stability but if that's not the case and everything becomes N sized, I'll keep things simple (adding the make install if some dev wants it)

Awebb · 2016-11-07 15:08:50

WebReflection wrote:

Or better, how would you publish some software to as many Linux distro as possible?

I don't say you shouldn't consider flat/snap/shoopdawoop packages, but please be advised, that the more traditional distros will refuse to work with binary releases. Distros don't want your precompiled package, because chances are you compiled that thing against some weird library version and whatnot. If you don't have the time to write the PKGBUILD, find someone from the community who will.

If you read the replies in this thread carefully, then you will notice that the best way to distribute your software to Arch Linux, is by providing a source repository and a transparent list of dependencies in your readme. Binary packages in the AUR are not exactly forbidden, but they are discouraged with a few exceptions.

WebReflection wrote:

that's how many more or less famous projects get usually installed, copy and pasting some line in the terminal (terminal runs usually in bash so yes, bash is present there) so I've done everything but reinventing a wheel.

At least once a month there is some article on some blog, where seasoned developers and admins cry out in pain about that "curl | bash" practice. That's not reinventing the wheel, sure, it's telling people to rocket jump to work and back. I write angry emails at devs myself, who put this in their readmes.

Please don't take this the wrong way, but I think you do not have enough experience in packaging to understand, why we are so strongly opposed to those flat packages. This is not uncommon among developers, that's probably why we usually let other people package our stuff. If I knew how to provide the insight without eating away all your free time for the next month, I would.

WebReflection wrote:

I'll keep things simple (adding the make install if some dev wants it)

Please ALWAYS do this. The moment you don't have a proper source release, you contribute to the dangerous notion, that Open Source is unnecessary.

Last edited by Awebb (2016-11-07 15:11:50)

Trilby · 2016-11-07 15:09:55

WebReflection wrote:

that's how many more or less famous projects get usually installed, copy and pasting some line in the terminal
... it requires that you have github, you clone the repo, you have make available as dev tool

None of this is true. None.

A lot of garbage is installed that way, yes. But that is coming from either 1) people who have no idea what they are doing or 2) developers who may be good at coding but are clueless about distribution and rather than learn they throw their hands up and accept the worst possible hack that sometimes gets the job done*.

My approach most definitely does not require that one have github. You could argue that it requires one has git which is an entirely different thing - but even that'd not be remotely true. If you can curl to download some ridiculous script, you can curl to download a source code file - it just needs to be publicly available somewhere for download: this much is true of *every* distribution method other than having people send you self-addressed envelopes that you drop disks into. Yes, a makefile would require that make was avialable, but I said the Makefile was optional. In the case of a single-file perl script, a Makefile is entirely unnecessary, but it's nice to throw it in anyways for those who do have make (which includes any distro packager).

But again, snap, flatpak, or any other of these options would in no way solve this "problem". Rather than having an optional use for `make` users would absolutely have to have the snap package manager.

There may be benefits of snap/flatpak (I'm skeptical, but there certainly could be) but you should most definitely not look to some flashy new tool to "fix" all the "problems" of current software distribution until you at least learn the most basic concepts of currently used software distribution methods. As an odd change, I think Scimmia is being to optimisitic: this is not becoming hopeless - it's already there.

*NOTE: The first part of this sentence is perfectly understandable. I don't think good coders need to know a lot about distributing software. They just write it and make it available. Leave the packaging to people who are good at it. A coder only need to know enough about packaging to not get in the way of or aggravate downstream packagers. The second half of the sentence is the problem: rather than either 1) accepting that distribution is not their job or 2) learning to do it decently, they just do it in an absolutely horrid way.

Awebb · 2016-11-07 15:15:07

Trilby, try to understand where WebReflection is coming from. He is a developer, who wants to be distro friendly. He probably has never ventured all the plains of packaging torment and he probably does not have our century of experience. Imagine driving through a remote place somewhere down south and you innocently ask for directions and - BAM! - shotgun wedding! How would you feel?

Trilby · 2016-11-07 15:17:36

Awebb, I was posting an edit (the NOTE) to clarify just that point. There is no problem with not knowing how to package. There is a problem with not knowing and doing it anyways. I don't feel bad about not being trained as a surgeon. But I also promise I will never offer someone an appendectomy.

WebReflection · 2016-11-07 15:20:28

by github I meant git, also because saying "you need to have github" makes no sense at all, it was a slip of the finger sicne i have the github repository and the package for the AUR module in here:
https://aur.archlinux.org/cgit/aur.git/ … D?h=echomd

So everything is there, but I don't care about echomd, I am trying to understand if there's interest in snaps. How this became a personal attack to me ruining the Open Source world for a script you can read and see with your eyes won't end up on the next developer face as tears is out of my understanding.

The binary package in question is also an open source perl file so I have no idea why you had to underline in such way I don't have experience packaging . If you read carefully my first post, I already said that so chill out and thanks regardless for answers, those that were actually related to the topic.

Thanks to others too, I think I've got after all the idea/answer I was looking for.

Last edited by WebReflection (2016-11-07 15:21:53)

eschwartz · 2016-11-09 01:50:01

You don't need git either, Github.com provides tarballs of the source code on the Releases page. No need to add the archive to your gh-pages branch to be hosted on GitHub Pages either!

A snap seems incredibly unnecessary given that the program is written in a scripted language and runs via an interpreter which is pretty darn likely to be on any computer (we shall not count Windows, for obvious reasons).

You really could just tell people to curl the script itself and output it to /usr/bin then chmod it... which can also be done in a one-liner.
Alternatively, if downloading the archive is okay but depending on Make isn't, offer an install.sh Makefile alternative.
If update notifications are a desired feature, you will have to depend on package repositories to keep on top if things (which assumes someone packaged it for that distro). Or embed a version check in the program, which rarely makes sense.

Snaps are no different from any other package repository, except they run on any distro, but require the user install Yet Another Package Manager. Oh, and they want you to depend on a containerized form of everything you might need, e.g. a standalone Perl snap. Which is silly.
Might I add that most people will not have flatpak or Snappy installed?

WebReflection · 2016-11-09 02:51:24

In case somebody else would like to mistake this post: it is not about echomd which is already hosted without any issue in AUR.

Best Regards

P.S. it's also already marked as solved

Last edited by WebReflection (2016-11-09 02:51:57)

eschwartz · 2016-11-09 03:24:29

Sorry, I didn't realize this thread was not about what you posted, and was instead about what you didn't post.
I should have guessed, considering how long it took to even get you to post an example of why you cared.

Maybe if you stopped being all secretive about what you want to know, we would stand a better chance of replying in some meaningful way...

Note that most of the advice you received was applicable to more than just that particular package. It covers a variety of things, including package best practices as well as the reasons why snaps don't work out.

WebReflection · 2016-11-09 03:27:41

I am quoting Awebb who summarised pretty well this thread which is flagged as solved so it does not need necro-bump

Trilby, try to understand where WebReflection is coming from. He is a developer, who wants to be distro friendly. He probably has never ventured all the plains of packaging torment and he probably does not have our century of experience. Imagine driving through a remote place somewhere down south and you innocently ask for directions and - BAM! - shotgun wedding! How would you feel?

Best Regards

Arch Linux

#1 2016-11-04 17:36:16

[SOLVED] Anyone publishing "snaps" ?

#2 2016-11-06 05:13:28

Re: [SOLVED] Anyone publishing "snaps" ?

#3 2016-11-07 10:24:52

Re: [SOLVED] Anyone publishing "snaps" ?

#4 2016-11-07 12:07:51

Re: [SOLVED] Anyone publishing "snaps" ?

#5 2016-11-07 12:20:49

Re: [SOLVED] Anyone publishing "snaps" ?

#6 2016-11-07 13:43:14

Re: [SOLVED] Anyone publishing "snaps" ?

#7 2016-11-07 13:53:59

Re: [SOLVED] Anyone publishing "snaps" ?

#8 2016-11-07 14:11:38

Re: [SOLVED] Anyone publishing "snaps" ?

#9 2016-11-07 14:29:14

Re: [SOLVED] Anyone publishing "snaps" ?

#10 2016-11-07 14:44:41

Re: [SOLVED] Anyone publishing "snaps" ?

#11 2016-11-07 14:50:27

Re: [SOLVED] Anyone publishing "snaps" ?

#12 2016-11-07 14:56:14

Re: [SOLVED] Anyone publishing "snaps" ?

#13 2016-11-07 14:58:58

Re: [SOLVED] Anyone publishing "snaps" ?

#14 2016-11-07 14:59:45

Re: [SOLVED] Anyone publishing "snaps" ?

#15 2016-11-07 15:02:10

Re: [SOLVED] Anyone publishing "snaps" ?

#16 2016-11-07 15:07:54

Re: [SOLVED] Anyone publishing "snaps" ?

#17 2016-11-07 15:08:50

Re: [SOLVED] Anyone publishing "snaps" ?

#18 2016-11-07 15:09:55

Re: [SOLVED] Anyone publishing "snaps" ?

#19 2016-11-07 15:15:07

Re: [SOLVED] Anyone publishing "snaps" ?

#20 2016-11-07 15:17:36

Re: [SOLVED] Anyone publishing "snaps" ?

#21 2016-11-07 15:20:28

Re: [SOLVED] Anyone publishing "snaps" ?

#22 2016-11-09 01:50:01

Re: [SOLVED] Anyone publishing "snaps" ?

#23 2016-11-09 02:51:24

Re: [SOLVED] Anyone publishing "snaps" ?

#24 2016-11-09 03:24:29

Re: [SOLVED] Anyone publishing "snaps" ?

#25 2016-11-09 03:27:41

Re: [SOLVED] Anyone publishing "snaps" ?

Board footer