On 10.08.2016 20:13, Dominique Leuenberger / DimStar wrote:
On Wed, 2016-08-10 at 19:55 +0500, Sergey Kondakov wrote:
Are you seriously arguing for obsolete packages in a supposedly "rolling" distribution while having 2 potential solutions presented:
I'm arguing at a distribution level - not at a package level.
1) Updating or fixing the actual broken package;
Have a go at it and submit it - don't demand for fixes to happen
Personally, I don't need fixes for vlc, I hate it. All those features, buttons and menus but none of them useful, unlike mpv. Other apps may soon start demanding fresh ffmpeg. It's funny how you wouldn't allow "my" packages to be updated until I "fix" "yours" all while you know several ways to do so better than I am and had a bunch of time of prior notice.
2) Backporting fixes for broken package or keeping its old dependency (which, being a library framework, supports parallel installation of multiple versions) ?
This was already stated by me as acceptable - but nobody seems to be willing to do the work
Backporting from that will probably would be like doing so from Firefox. A mess. What work exactly has to be made to copy Factory's ffmpeg as ffmpeg2 and set dependency version in "stable" package of VLC ? Can't you do it instead of halting entirety of A/V stack for weeks or months for the package that has its non-released version fine and working ? Although, when I was doing something similar, OBS tried to ignore any ffmpeg version other than the latest. Is there a way to feed it ffmpeg 2.x tarball as its "contrib" version via spec so it would build it and statically link with it or whatever it does by default ? If so and this is upstream's attitude - https://trac.videolan.org/vlc/ticket/17248, that probably should be default for "stable" vlc package because of how lazily it updates and how small its improvements are.
But I take this as 'VLC is obsolete and should be removed from the distribution'? Fine by me... There is no VLC out yet that supports the new API - backporting the diff from the 3.0 branch is not straight forward.
And I'm sure I can use this argumentation to drop anything that stops building at any moment in the future, right? because 'we are rolling' we don't care for things that can't keep up with the pace?
This is not what I said, I said: keep working bleeding edge version as primary until working release, backport from it or keep its dependency until update. You argue for neither. I already got a taste of you people not fixing and just dropping packages left and right. Even working ones. How this even supposed to be tested if ffmpeg 3.x is currently broken because https://build.opensuse.org/request/show/417360 isn't merged but https://build.opensuse.org/request/show/415435 was ?
And the counter-argument against you is "Noone cares about non-OBS buildservices", "ffmpeg is not special." ?
Which I countered by 'it's not true' - read all my text, not only the pieces that interest you
And so do you.
I don't even know which one is more baffling. I wonder, do any of you actually using your personal system without multimedia apps at all ? Do you even have X-server installed ?
What? do any of us use a personal system WITHOUT multimedia apps? you must be confused, so I'll answer as if you would have asked 'WITH multimedia apps'
Yes, I even regularly use VLC (amongst others) and do not want it to be broken - including the addon codecs - by bringing a package in the distribution that obviously breaks it. And I do not want to have the two well-known 3rd party OBS instances break my system when I add their packages. There is sufficient trouble with addon repos without forcing it.
No, you're the one confused, I wrote "without" and I meant it. Because consistently so little care is given by most official maintainers to fundamental A/V support, that you must be using useless, gutted builds for multimedia or none at all. Therefore I wonder if people who do either even really exist and, if so, which is it. But then again, a distribution installer was dropped form its repo. So what is measly A/V support after that ? Might as well drop kernel or build it with all modules disabled. Argh, if I had any I would pay billions to buy out, move it to Russia and develop open/SUSE and/or Sailfish as desktop/mobile enduser no-bell-and-whistles distribution to rival MacOS. Just so it would be 100% maintained and developed full-time.
Anyway, if the real issue is with VLC, then you shouldn't bother with too many hacks or risk ffmpeg bitrotting. VLC maybe popular on Windows but it's just too damn clunky and slow-developing. Unless vlc-beta isn't working _and_ there is no patches to backport, don't even waste time pondering, update ffmpeg !
Again: I take this as request to drop VLC - I'm fine with this approach too.... but I do not want to hear any complaints from anywhere.
Cheers, Dominique
If you've accepted ffmpeg 3.x break-inducing hdf5 update into Factory, you can sit on broken stable vlc just until its update since you will even have working unstable version in the meantime. Or bother to copy 1 already in-Factory package temporary instead of arguing in kilobytes of mail. That's why I, as many others, rarely commit anything into Factory, spares the "banter" with people who keen on breaking but not so much on fixing even for themselves. So don't twist my words into encouragement of typical openSUSE drop-frenzy.