Request core18-3.4 track for ffmpeg-sdk-gplv3 stage snap


#1

Dear @reviewers, I would like to request a core18-3.4 track for the ffmpeg-sdk-gplv3 stage snap as one of my consuming snaps isn’t compatible the latest release of FFmpeg (4.1) and requires specifically 3.4.x version.

Thanks in advance!


Track request(16) for the zenity-integration snap
#2

On second thought maybe I should use the ffmpeg-sdk namespace and request the core18-3.4-gplv3 track instead?


#3

I’m -1 to granting tracks for a snap whose sole purpose is to be used as a library (per The FFmpeg SDK stage snaps). Tracks are meant to “give a group of users the ability to stay on a robust, proven version of their software, even when a newer stable version has been released. Using a track can be useful if the newer stable version has some backward-incompatibilities”. Also, if I understand this correctly, it’s the same software with only licensing differences which I don’t think fits the intended use of tracks.

  • Daniel

#4

Well it depends on the perspective of what the users are, for library stage snaps the users are the consumer snaps, which also require to stay on the compatible release of the depending libraries.

The licensing part can be excluded from the track, in this case base_name-release_name might be a good candidate.


Track request(16) for the zenity-integration snap
#5

Hello!
Thanks for explaining.

Can you please reiterate the snap and track you are asking for? because at this point, it’s unclear what the request is for.

With that, we can start the timer on the voting period and gather reviewer/architect votes per Process for aliases, auto-connections and tracks.

Thanks!


#6

I’ve updated the request, please review.


#7

Thanks! Now it’s clear: "core18-3.4 track for the ffmpeg-sdk-gplv3 [snap]".

I think we can take the date of original request as the starting time, that’ll get us faster resolution. We’ll check back on Friday to see if we have enough votes to make a decision (remember: need +2/-2 majority OR an overriding vote by an architect). If by Friday there aren’t enough votes, I’ll request an extension to the voting period.

Cheers,

  • Daniel

#8

@reviewers, could we get some votes/opinions on this track?

The voting period ended without enough votes; extending until April 22nd (7 more days).

  • Daniel

#9

Pinging @reviewers again for votes on this track request, and extending the voting period further to April 30th.

  • Daniel

#10

+1 on core18-3.4 track.


#11

Hello @reviewers,

Poking again, could use some more votes on this track request (Current tally is +1/-1). Extending voting period until May 3rd.

  • Daniel

#12

Considering Daniel’s comments regarding “give a group of users the ability to stay on a robust, proven version of their software, even when a newer stable version has been released” and @Lin-Buo-Ren’s response that consumers of staging snaps are a form of user, I’m inclined to vote in favor of this. However, I do wonder what the incompatibility is before doing so. @Lin-Buo-Ren, can you comment?


Track request(16) for the zenity-integration snap
#13

It’s a direct failed to build from source, due to API breakage, here’s a (similar) one on the upstream tracker: guvcview / Tickets / #44 building against ffmpeg 3.5 fails


#14

IMHO, stage snaps can be thought of sorta like content snaps at build time. With content snaps we have the notion of naming the “content” field in a way that expresses where it came from and very course versioning (eg, “gnome-3-26-1604”). Stage snaps on their own don’t have this concept inherently so a track request does make some sense.

That said, I wonder if it makes sense for the ffmpeg snap to provide a content interface with a similar naming convention that when you stage it you get those libraries. Admittedly, this is stretching the concept of the content interface as well.

@pedronis - I don’t typically vote on track requests, but considering @noise comments in Track request(classic) for the tree snap, to be safe, could you weigh in on the concept of using tracks for stage snaps in this manner? Perhaps @roadmr could update the documentation if needed. Thanks!


#15

This is a case where there’s build time (stage snap) snap but not a runtime one? what should happen if both existed? in the latter case different snaps or multiple content slots, with different content labels would need to be used.

I image this is viable because snapcraft let’s specify a track here? (@sergiusens ?) while snapd doesn’t for bases or content snaps.

All of:

  • multiple snaps
  • multiple tracks
  • one snaps with multiple dirs/content labels

are possible. I worry slightly about the confusion from the asymmetries between what snapcraft can allow and what snapd does.


#16

I do not think we should compare stage-snaps to the content interface. Staging a snap can replace the functionality of what a content interface might provide just as much as filling that functionality with stage-packages in a part or by building from sources.

I thought the entire reason for having snaps using the content interface was to have a clear expectation of ABI and API while snaps in general do not have that requirement.

We have channel support in stage-snaps to have symmetry with build-snaps in the snapcraft domain, which is why I am -1 in conflating this as a perfect fit replacement for a snap using the content interface which by properties in snapd should be replaceable as it is an implementation of an interface and not a dependency.


#17

Where do the link-time libraries of something like gnome-3-28-1804 come at build time? could that be a stage snap?


#18

It could, but it is not, it is done through stage-packages.


#19

Would they be multiple snaps as the runtime snaps themselves (gnome-3-26-1604 vs gnome-3-28-1804) ? that’s where my slight worry comes from.