Aliases for Volatility

store-requests
1

Hello,

I would like an alias to volatility.

for this snap:

Thank you!

2

Have you considered contributing the snap to the upstream Volatility project rather than under a namespaced snap name?

Having the ‘real’ volatility name in the store would mean you wouldn’t need the alias at all, as it would automatically be the right alias name.

In addition, you don’t have a ‘vol’ entry in your snapcraft.yaml, so even if you had the vol alias, it wouldn’t work.

3

Not yet, but it makes sense on second thought.

I was rather experimenting with the technology and make a package that works for my students and anyone who find it interesting. Nothing too serious in other words.

Let me contact them and tell you.

But if they are not reactive, I would really like to get these aliases. That would be much more convenient for my work, I have real needs.

4

@popey

Done: https://github.com/volatilityfoundation/volatility/issues/624

Meanwhile, I still would like an alias for volatility.

Is this violating any policy?

5

It’s not violating any policy, but it just looks a bit wonky. We don’t have the capability to rename snaps in the store. So presuming your volatility-phocean snap becomes wildly popular, and the upstream volaticity devs say “yes please, we’d like to manage that now” - they end up with a snap called volaticity-phocean, which they can’t change. They could upload a new “official” volaticity snap, but then there would be two, and “your” users would be on the “unofficial” one, with no simple/straightforward way to move them over.

Whereas if you had the “official” (non-namespaced) name, the transition later would be much easier. Make sense?

6

That’s why I am offering them to delete (or make private) mine as soon as there is an official one. Isn’t it a different topic than my original request?

And, I might still want to package another branch if this is required for my work : different branch, community plugins that are not maintream, etc.

Anyway, I still don’t get what’s the point with the alias, my initial request.

Why would it be an issue that an unofficial snap gets the same alias as an official one? This is the responsibility of users to know what they are installing.

For example, gqrx-lool does exactly that: Install gqrx-lool on Linux | Snap Store.

Anyway, if you still don’t want to provide my snap with this alias, let’s move on. I will ask the users to do it manually… :frowning:

7

I think what Popey is getting at is that we think it would be better if you used this repo for your snap (fork and edit it) and follow the steps in it to get an upstream snap :slight_smile:

Let us know if you have any objections to that process :slight_smile: we think upstreams would more readily take on your snap if you did that rather than appending your name to it, and, when your snap is transferred to the snapcrafters GitHub org, it gets the benefit of being semi-official by having the snapcrafters name as the developer of the snap, until the time that the upstream is happy to maintain the snap, in which case ownership is simply transferred, no deletion and recreation necessary :slight_smile:

I have no authority to +1 this request I’m afraid (I’m just a member of the snapcrafters GitHub org, not a snappy dev), so can’t help you with your request, but I do support Popey’s suggestion :slight_smile:

Ignore this (see @popey 's reply)

8

I think what Popey is getting at is that we think it would be better if you used this repo for your snap

I followed the official documentation for every step, and at no point snapcrafter was mentioned. And I fail to understand the relationship with my request. Okay, the procedure may be better, but then?

we think upstreams would more readily take on your snap

In the case of Volatility, and most of the other packaging stuff I am working on, I am sure that upstream does not care, otherwise they would already have a snap, or any other form of packaging.

For the rest, I understand your point of view, but here are my objections:

  • I am a user, infosec guy, not a maintainer / upstream developper / sysadmin. Does it mean that the snap store is hostile to users and just want upstream maintainers?

  • I have not received a clear answer, like YES or NO, and it seems there is no clear policy. Per the documentation, I see nothing that states why I would not get a simple alias.

  • All the process you mention requires a lot of time and efforts. I just wanted a way to quickly and reliably deploy some stuff to my students.

I planned to make some snap for another handful of application, mostly software defined radio.

These apps are a pain to install, not necessarily actively maintained, and I guess many users would be happy with my work.

Too much energy wasted in this discussion, I just hope to have a clear status now.

9

No, I didn’t say nor suggest that, and I’m not advocating that at all. Please don’t second guess what I’m suggesting. I was very clear.

1 Like
10

It isn’t that we don’t want to grant the alias. We are trying to guide the process so your users have the best experience. If you decide to rename the snap to ‘volatility’ then there is no point granting that alias since you can have command under ‘apps’ named volatility and get that alias automatically. We would then need to process the request for ‘vol’, but there is no point in doing that prior to the rename. If you decide not to rename, then we can proceed with both.

Based on @popey’s comments, are you planning to rename your snap?

1 Like
11

I almost gave up on snap, so thank you for answering.

As I suspected, upstream won’t answer anytime soon, and I think they won’t care about packaging.
And I am realizing that getting every upstream project to contribute a snap will be too much for the free time I have, because I plan to work on quite a lot of apps.

So, I do not plan to rename the snap.

And yes, I want an alias to volatility. And just this, forget the rest.

Thank you.

12

+1 for the volatility alias

@reviewers - can others vote?

13

+1 on the volatility alias. I would prefer to see a volatility snap since namespaced snaps are awkward but the requester is aware of this and has chosen not to go that route, so the alias makes sense and is unique enough.

  • Daniel
14

How and when is the voting process going to end?

15

2 votes for, 0 against. Granting use of the volatility alias. This is now live.