[PUP-7435] Add support for snap packages Created: 2017/04/07  Updated: 2019/12/30

Status: Accepted
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Matthias Baur Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: linux, package, type_and_provider
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Team: Platform OS
QA Risk Assessment: Needs Assessment

 Description   

Could we get support for snap package? https://snapcraft.io/

This should probably be implemented as package provider.



 Comments   
Comment by Peter Bittner [ 2017/09/04 ]

This would be helpful. JetBrains, for example, are in the process to create snap packages for their IDE products (IntelliJ IDEA, Webstorm, RubyMine, PyCharm, PhpStorm, etc.). They're dropping the request for creating .deb and .rpm packages for that.

Comment by Jeremy Adams [ 2018/02/08 ]

snap is the preferred install method for kubectl cli per https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu

 

 

Comment by Igor Galić [ 2018/07/24 ]

Here's a discussion between me and David Schmitt which concludes that we should probably not put snap support into package as it would break a lot of package's expectations:

 

 igalic: how would you implement channels? i'm contemplating to reuse "source"
 although that might be very misleading…
 
david: how much overlap is there really to regular packagem anagers? wouldn't a separate snap_package be much nicer, when it can expose all the snap-specific whistles, without having to avoid all the existing type's issues?
 
igalic: so, from what i gather, there's slightly more overlap between snap and apt (on a systems level) than there is between apt and pip
 for instance: snap packages will come with services, these services will *actually* _*use*_ systemd.
 
david: I'm running on assumptions here, but: snap and apt packages do not have overlapping namespaces, install options, or shared configuration, right?
 
igalic:  define install options
david:  any options passed to apt-get or the snap binary
 
igalic: "install"
igalic: let's see if we can boil this down:
 
snap allows you to install a… "snap"
but you can also "buy" a snap.
snap services allows you to manage services, akin… well, the system's "service" command. so, start, stop, restart.
snap get/set allow you to set or retrieve specific config settings… this is probably best compared with SMF's config settings… i.e.: things you def want to setup before starting a daemon… so, like, in apache that woulda been MPM selection, or logging or stuff like that… maybe logging destination in some cases
 
david: `--force-downgrade`, et al. ?
 
igalic: have i told you the best thing yet?
snaps auto-refresh ;)
i wonder how hard a `package { 'foo': provider => 'snap', ensure => '1.2.3', }` would have to work, to earn its keep
 
igalic: yeah, so, given these issues, `snap` should probably be… something else.

Comment by Hadmut Danisch [ 2019/12/30 ]

Sorry to say that, but that discussion is bigoted nonsense.

 

snap has become an established package source, offering plenty of software, and is beginning to replace several ubuntu packages. Some pieces of important software is available as a snap only. And other software gets newer versions only as a snap.

 

Puppet's denial to support the package format is just rendering puppet into beeing unable to install machines in a clean way.

 

snapd comes with a description of it's REST API at https://github.com/snapcore/snapd/wiki/REST-API , so it should be quite simple to tell snapd to install or uninstall a requested package.

Unfortunately and in contrast, I did not find a detailed description about how to implement a package provider for puppet.

 

Strange enough, there's a module for that, https://forge.puppet.com/kemra102/snapd , but not exactly maintained, not yet complete, and based on the command line snap tool, not the REST API.

 

So it should be a small and simple task to implement this for someone familiar with the internals of puppet for this REST API.

 

 

So if you want puppet to be able to configure today's systems, puppet needs to keep up with today's systems.

 

And if puppet is not able to properly install current systems anymore, than this is not just a feature request anymore. It's a bug, since installation becomes partly impossible (in a clean way without workarounds). 

 

Comment by David Schmitt [ 2019/12/30 ]

FTR I'd like to emphasise that Igor Galić and my discussion was specifically about the difficulties putting snap support into the package type as a provider.

Generated at Mon Jan 27 11:41:30 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.