xvid used to be pretty popular in the early 2000s which made some
sense to have as default, but nowadays it is nothing but a relic
and users that really want it should opt-in manually.
Also, on media-video/ffmpeg, last I know of USE=xvid should not be
needed for xvid playback and that USE is rather only for encoding which
even less people should need as they'll use more modern codecs.
This means "most" video players should still be able to play these
likely very old files without issues.
One negative impact this change will have is with media-gfx/blender
which seems to need a list of encoders always enabled incl. xvid
(unsure if it really still needs xvid in 2026 though).
ffmpeg? ( media-video/ffmpeg:=[encode(+),lame(-),jpeg2k?,opus,
theora,vorbis,vpx,x264,xvid] )
..most of which are already off-by-default, but users will need to
update their package.use to also add xvid -- may cause some confusion.
On a related note, only a handful of package even (still) have the USE,
which also makes it questionable set globally rather than per-package if
needed:
* media-libs/avidemux-plugins
* media-tv/mythtv
* media-video/ffmpeg
* media-video/ffmpeg-compat
* media-video/gpac
* media-video/mplayer
media-libs/xvid also hasn't received a release in 6 years, could
potentially become a last-rite candidate if it breaks. No longer
pulling that ancient package by default for ffmpeg users is the
primary benefit here.
Bug: https://bugs.gentoo.org/831211
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Unmask new dev-python/setuptools-scm and dev-python/vcs-versioning, now
that the dependency cycle is (hopefully) resolved.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
This goes back further I suppose but it only started to matter with
e244fab5ad as otherwise we installed
just headers.
Avoids cross-i686-gnu/hurd installing to the wrong libdir:
```
/usr/i686-gnu/usr/lib64
/usr/i686-gnu/usr/lib64/libihash.a
/usr/i686-gnu/usr/lib64/libihash.so
/usr/i686-gnu/usr/lib64/libihash.so.0.3
/usr/i686-gnu/usr/lib64/libihash_pic.a
/usr/i686-gnu/usr/lib64/libirqhelp.a
/usr/i686-gnu/usr/lib64/libirqhelp.so
/usr/i686-gnu/usr/lib64/libirqhelp.so.0.3
/usr/i686-gnu/usr/lib64/libirqhelp_pic.a
/usr/i686-gnu/usr/lib64/libshouldbeinlibc.a
/usr/i686-gnu/usr/lib64/libshouldbeinlibc.so
/usr/i686-gnu/usr/lib64/libshouldbeinlibc.so.0.3
/usr/i686-gnu/usr/lib64/libshouldbeinlibc_pic.a
/usr/i686-gnu/usr/lib64/libstore.a
/usr/i686-gnu/usr/lib64/libstore.so
/usr/i686-gnu/usr/lib64/libstore.so.0.3
/usr/i686-gnu/usr/lib64/libstore_concat.a
/usr/i686-gnu/usr/lib64/libstore_copy.a
/usr/i686-gnu/usr/lib64/libstore_device.a
/usr/i686-gnu/usr/lib64/libstore_file.a
/usr/i686-gnu/usr/lib64/libstore_ileave.a
/usr/i686-gnu/usr/lib64/libstore_memobj.a
/usr/i686-gnu/usr/lib64/libstore_module.a
/usr/i686-gnu/usr/lib64/libstore_mvol.a
/usr/i686-gnu/usr/lib64/libstore_nbd.a
/usr/i686-gnu/usr/lib64/libstore_pic.a
/usr/i686-gnu/usr/lib64/libstore_remap.a
/usr/i686-gnu/usr/lib64/libstore_task.a
/usr/i686-gnu/usr/lib64/libstore_zero.a
```
Fixes: e244fab5ad
Signed-off-by: Sam James <sam@gentoo.org>
Not tested wine much but should hopefully be uneventful, same gcc
version and runtime-14.0.0 does not seem very different from 13.
While here, clean up the old postinst warning about duplicate
toolchains, this been established for a while and users that have
both installed must be doing it on purpose at this point (esp.
since bin-symlinks was flipped on by default and would conflict).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Viorel Munteanu
Ionen Wolkens
Ulrich Müller
Sam James
Michał Górny
Andreas K. Hüttel
Bernard Cafarelli
James Le Cuirot
Eli Schwartz