External repositories

@Conan_Kudo Both Zygmunt and I are talking to you as the actual well known snapd and Fedora contributor that you are. We all appreciate your efforts a lot, as we hope you appreciate ours into making sure things work well for you. The fact we’d like to have more people collaborating and that we won’t detour our focus and perform a major investment into federating stores without more clear engagements is not about you.

1 Like

@lance, indeed what is hardcoded in the core.snap we can’t deal with it.
But! snapd could just look first in some independent place. In the gadget snap for example. This is the perfect place for that.
The gadget snap should define the base URL of a store. And all specific store assertions/signatures. All that snapd should do is just obey to these credentials, that’s all that necessary.

Why’s that? Not true at all.

It seems that you’re trying to confuse and obscure everything in that field.

So to conclude:

  1. gadget snap defines store base URL and its keys
  2. snapd obeys that info
  3. That’s all.

All additional functions is up to the external store. This external store could even resign snaps from Ubuntu Store with his own cryptokeys to match those defined in gadget snap. (In the case that you continue to insist that it’s oh-oh-oh so impossible to implement an array of dictionaries defining multiple stores) The first candidate for this re-sign procedure is the core snap of course.

Neal I didn’t mean to offend you in any way. I was talking about the general feedback we are getting from the forum. There a lot of people here that want snapd to do something or to have a specific feature. I just wanted to convey the feeling that we need hands making this available. As Gustavo said already, you are an invaluable member of the team. You insight into many matters related to Fedora and the broader landscape has helped us steer the ship the right way. Your patient and tireless work on Fedora is very much appreciated. I also personally hope to call you my friend and I love our discussions where we agree and disagree on diverse topics.

2 Likes

that’s why it’s split, now that store can decide “foo” is any piece of software, matching or not the snap ecosystem idea of what software/snap is “foo”.

Even in a federated world because of UX we would like for “foo” to identify one software in most common cases. That means some federated registration mechanism with some arbitration.

If users need to think about store1:foo vs store2:foo in a lot of cases, or developers need to resubmit or release manage the same software many times we are going backward UX wise I think.

4 Likes

The quality of the conversation here is quickly decreasing. Let’s please try to keep it respectful, otherwise it stops being worth having it in the first place.

I think this is a great point and a good guiding principle for desktop UX. The problem I see with the argument from UX is that snaps are advertised as being useful not just for desktop users but also IoT and servers. I cannot comment on running distributions, but I think in the IoT space, the person doing system integration arguably needs tight control over the software running on devices. There, the UX argument is irrelevant, as end users are not logging into the device and typing “snap install” commands. Giving snapd a little bit of configurability, as @denis suggested, seems like good design and makes it more flexible for these different use cases.

2 Likes

It’s a great and bright idea not to overlap in any case. Even with some aliens living on Alpha Centauri and managing their own snap store. In a long term perspective why not. Not even a slight shadow of sarcasm, I really appreciate your broad vision and how it can simplify simple end users’ life. Maybe we will end up with a blockchain signing developers’ snap/application names, who knows, this is a distant future.

But today for some cases it’s an overkill, I suppose. You mean that stores are just namespaces. Snaps have their visibility scopes. For developers this is so natural to deal with, like OOP.
For users who don’t bother, they just use “foo” with no namespaces at all. Ubuntu could use the global scope.

But even that should not be the first step. The first step could be a mono-store concept with the ability to change its URL. This gives minimal intervention in snapd logic. In that case Canonical’s core developers stay focused on their main goals.

But still this gives other people an understanding that they can invest their time with little risks in the future. And a relief that Canonical doesn’t want to become Apple Inc and all that is going to be a dead end.

1 Like

Building off this idea, I think it is mostly just a small change around this section of code in order to read configuration from some place other than a string literal or an environment variable. It would be perfect if the URL(s) could come from the model assertion or gadget snap somehow. I think the gadget snap can initialize snap configuration. Could that work? I think there is also the matter of key management for snap assertions, but I admittedly do not fully understand that aspect yet.

@denis Please have a look at our communication guidelines. Once more, this is a civilized place for public discussion. We need everyone participating here to understand that, because otherwise everyone’s ability to communicate, interact, and be productive here will be affected.

2 Likes

@lance It’s no different on that space really. In fact, quite a few of our very early customers are actually from the specialized device space rather than desktops. They do appreciate that focus.

To try and contribute something new here…if (theoretically) other parties were interested and willing to put work in, would Canonical be interested in some sort of joint ownership of the store? Canonical owning the snappy store alone seems to not go down well with people because they worry about Canonical rejecting certain snaps - maybe they would be controversial or super-big - perhaps some sort of more nuanced ownership of the store would help trust-wise? Also Canonical owning the store seems problematic for people because it doesn’t look very distro-neutral to them - Canonical holds the cards.

I don’t know if this is possible, but it’s just a thought :slight_smile:

If this is not possible, if Canonical solely owning the only store supported by snapd is the only way we can go, does the snappy team have any suggestions on how to defend this to people who distrust Canonical and its sole ownership of the snappy store? Maybe I shouldn’t bother defending snappy on Disqus etc (though I rather enjoy doing so) but would be nice to attempt to garner more support for snappy by doing this (maybe I won’t persuade the people I argue with, but other people often read the comments and may be persuaded by argument…) - by showing that it isn’t the scary Ubuntu-y thing that it is in some people’s minds. Hope I don’t seem too aggressive.

I could try saying ‘look, Canonical really isn’t that scary, they’re paying for all of the snappy team, no other company is, why can’t they run the store’… but then maybe more companies would pile in if the store was more ‘neutral’, but they may have other objections… ugh. It’s a bit chicken and egg really.

Also kudos to the snappy devs for engaging with these ideas :slight_smile:

Why don’t we copy the blockchain concept? Instead of recording money records, track down product updates?

Here is how it would work: Every developer gets a special certificate. If that certificate is lost, they might not be able to update their apps, but Ubuntu, Solus (brand store) and others would offer record-keeping services to hold those certificates. Every time a developer wants to update an app, they sign it with their certificate, which goes against the chain. The chain doesn’t contain the app files, but rather a list of valid releases that the developer approved. When a developer posts a new update, it appears on the chain which is run by Ubuntu and any other distros in joint operation. When a new version appears, all the distribution stores see it and fetch a copy from a store that has it.

Just a weird thought.

Here’s part two of this post: This is definitely chicken-and-egg. So, break that cycle Ubuntu! Build a snap store and open up a wizard to submit an application. Follow everything in my proposal (not to sound proud, just honest) and Snap will succeed big-time.

@Ads20000 Your interest and collaboration towards making people understand the proposal and the constraints we live under is certainly appreciated. The many exchanges here including the first few messages that go into some more depth about what we’re trying to achieve, should provide a good basis for conversations around the topic.

It’s also worth keeping in mind that this is not a one way avenue. Our plans are dynamic and we’re listening to feedback and doing our best to make sure we’re working on the most important problems, which means these plans can always change if other problems become more important, and we may end up working on federation sooner than I expect right now.

The main issue with federation, though, is that it’s not even a single time cost. It will slow us down significantly when doing many of the upcoming features which are on the pipeline. As you know since you’ve around for a while, there are so many things we’re working on right now, and so many other interesting features coming as soon as we can get a moment to work on them… We literally have multiple software vendors waiting for specific features to land so that they can transition their users to snaps. Meanwhile, federation wouldn’t change much the experience of any of the parties involved in the process… not for users, not for developers, and not even for the distributions that choose to ship snapd. It’s mainly about trust on who hosts the service, as you point out. That’s why our choice right now is to focus on that and push the federation problem to the future.

We won’t get everybody to agree with that view for sure, because perspectives are different, and everyone is entitled to a choice on how the future should look like, but I think we’re doing what’s best for the project and for the majority of people that care about such problems.

2 Likes

Now that the conversation has cooled down a bit I’m going to close this topic temporarily so that we all have some time to think about what everyone said here and so that we can focus on other things for a while. This will be reopened automatically in a few days.

3 Likes

This topic was automatically opened after 5 days.

Okay, so here is what I’ve got:

  • KDE Neon (seems) to want to use Snap, and we have Falkon web browser as a snap right now.
  • The problem with the centralized design is both trust and reliablity. If something went really wrong with Canonical’s servers, we don’t want to knock out every Linux distro that uses Snap. Trust is also important, because some people might just plain prefer to host snaps themselves.
  • In my personal opinion, having distribution stores would be ideal (see my long post above some distance)

However, the move away from the centralized design for Snap is going to be delayed, because Snap developers are busy working on other things. This is OK, as these features may need to be added first. However, just an official word from Canonical, like an obvious roadmap on snapcraft.io (the README in snapd doesn’t count) which says that distribution stores will come in the future is important. Just letting people know that it will come eventually could help boost confidence in Snap.

Ultimately, the federation problem can be handled in the future (and it should, given the circumstances), but a statement that Ubuntu will try to support distribution stores is better than nothing.

Now the thread changes topic: How should External Repositories / Distribution Stores be developed when the time comes for them to be developed? Again, check Distribution Stores post on what I believe is important when distribution stores come (if ever, though hopefully they will).

1 Like

@G.S.1 How do you feel about the epochs feature, that enables us to release software and control exactly which specific revisions of a snap someone should update to so that data migrations happen safely and correctly, and in a tested path.

Or how about base snaps, a feature that we’re eager to land as it will enable arbitrary base filesystems instead of what is fixed by the core snap.

Or layouts, enabling people to define arbitrary filesystem layouts inside their own snaps without affecting the rest of the system. Yet, without losing the read-only, compressed, atomic nature of snaps.

How about multi user support, which will allow snaps to support multiple users and collaborate with the host system in that regard.

Snapshots… We’ll have the ability to perform multiple data snapshots for every snap, with nice semantics on removals.

Or… being able to install the same snap multiple times, in parallel. I’m looking forward to that one, which allows a single snap to be present in the system multiple times, with independent identities. Say, two different versions of your preferred database, for example, to satisfy different applications.

Statistics… Health-checks… Staged deployments…
.
.

So… that list is real. This is part of what we’re focused on right now. It’s also the essential reason why I cannot possibly satisfy the request for even more details about federation today than the extensive responses provided above, which already includes the statement you are asking for and much more. That’s also true of any other large feature that is not on our roadmap already.

Over the next several months, you’ll see everybody in the team working hard to design, and then implement, review, and land those features and many others that continue to focus on having a software delivery platform we’ll all be happy to work with.

4 Likes

Waaaaa, do you have a link for that? I remember asking for the possibility of installing development versions alongside stable versions and was told it would be insecure, but this feature will actually land in some form?!

1 Like

Those features upcoming look great. Be sure to get to federation at some point though. :slight_smile:

Another thing I would like to see would be a more detailed introduction to Snaps from a distribution owner’s (or team’s) perspective. Tell them the specific reasons why Snap is superior to Deb/RPM/Flatpak, give links to the pages which say how Snaps work, cover the issue of Federation as it stands right now and how it will (hopefully) be in the future, and also cover things like snap sizes and other now-known-to-be myths surrounding Snap.

In other words, an Introduction to Snap for a Distribution Team’s perspective.