On Sun, Mar 09, 2025 at 12:45:37PM -0400, Eli Schwartz wrote: > On 3/8/25 10:34 PM, Ionen Wolkens wrote: > > Sending this to dev ML in advance given it's simple and "probably" > > won't need to change the code further. > > > > If interested in the whole deal, see the PR instead: > > https://github.com/gentoo/gentoo/pull/40942 > > > > --- (actual commit message below) > > > > Both the slotting method and eclass are meant to be as simple > > as possible, and isolated so that it does not really need to > > work with everything given non-slotted ffmpeg stays. > > > > Did not want turn ffmpeg into a permanent slotting model with > > a FFMPEG_SLOT use_expand, eselect, or such potentially turning > > it into a special Gentoo-only thing that often need hacks. > > > > Essentially just a way for broken packages to gain time without > > blocking everyone's ffmpeg updates. > > > What's the advantage of this over, say, just having ffmpeg itself with > slotting, but only supporting the tools with the latest slot and having > all old versions be library-only? > If you anyways have to modify packages relying on older versions as soon > as a newer version goes stable, then it seems like there shouldn't be a > major difference here. And keeping it all in one PN would mean you don't > have issues with ffmpeg and ffmpeg-compat wanting to install each > others' libraries and maybe ending up with both installed. You also > wouldn't need to e.g. maintain the same patchset for multiple packages.
Having packages that behave differently within the same namespace
sound confusing to me (and likely to users too). Not only will they have
no tools, but have headers and pkg-config files in non-standard
locations (if not renamed, but that's not better). It's essentially a
slot that's only for other ebuilds, not users.
Don't like the idea of juggling which version provides what too.
Like stable ffmpeg-6.1.2 w/ tools, ~arch ffmpeg-6.1.2-r1 w/o tools
plus ~arch ffmpeg-7.1.1 w/ tools. Kind of confusing and not clear-cut.
Plus we may want to keep several branches and versions, maybe a user
actually wants ffmpeg-6's tools due to some niche regression until
it's fixed. Having all this under media-video/ffmpeg feels messy.
wrt same time, if we *really* don't want that, could always have them
either block each others until versions get cleaned up, it ends up
being the same save for the patches bit.
...but it feels like an unnecessary restriction to me, even if we sync
up all stabilizations perfectly, users will do still accept_keywords
and such (esp. ~arch-only packages) and then run into blockers without
necessarily wanting the latest ffmpeg too.
Also, I'm hoping for usage of ffmpeg-compat to be really low. It's
meant to be a isolated last resort, new ffmpeg major versions will
still be added masked, then we'll try to fix most packages esp.
popular ones, and then give ffmpeg-compat to the rest and hopefully
not get it on many users' system. Problem is that (right now) it's
staying masked for way too long.
wrt patches, current ffmpeg-compat is sharing patches through a tarball
right now, good excuse to kill the 128kB files/ -- not that we couldn't
duplicate a few patches on short notice (but I agree it's not ideal).
The ebuilds are also identical, ffmpeg-compat is not meant to be
maintained on its own until the non-compat equivalent is removed,
just copy incl. keywords. The ${PN} change currently acts as the
trigger to become slotted (not that changing a variable instead would
be a big deal).
--
ionen
signature.asc
Description: PGP signature
