Le lun. 20 juin 2016 à 08:29, Dave Plater a écrit :
> On 6/19/16, Richard Brown wrote:
> > On 19 June 2016 at 16:41, Dave Plater wrote:
> >>> The pkg in multimedia:libs is about one hundred, thousand, million
> >>> times more at risk of being broken than the pkg in Factory
> >>
> >> Not if it's well maintained
> >
> > There is _NO SUCH THING_ as a well maintained Devel Project.
> >
> > https://en.opensuse.org/openSUSE:Factory_development_model
> >
> > They EXIST to be where things are put together, broken and ultimately
> > fixed before being submitted to Factory for testing into Tumbleweed
> >
> > A Devel Project which doesn't break from time to time is not doing
> > it's job properly.
> Firstly, I've been a multimedia and other single packages, package
> maintainer in openSUSE since 2009 and fixed many bugs. I think that my
> opinion is qualified. Breakages used to occur in Factory and now they
> are picked up in Tumbleweed and they are fixed in a branch of the
> devel project. Upstream releases packages that have been tested across
> the entire Linux spectrum of distributions. If I pick up a breakage I
> first look if it has been fixed upstream in git or whatever revision
> control system is used and apply a patch.
>
And yet, using a devel project as a basis for packages for Leap is wrong
(to TW, maybe less, but this is debatable). It forces users to
switch the entire gstreamer stack to Packman, including major version
upgrade of this stack for no good reason other than "this is the version
which is in devel project".
zypper dup is NOT something which should be advocated to Leap users.
>>>
> >>> Because it's a devel project, where packages are MEANT to be broken
> >>> from time to time, meanwhile we KNOW the ffmpeg packages in Factory
> >>> work as they get tested in openQA as part of the VLC testing.
> >>>
> >>> I've said it before and I'll say it again Packman building against
> >>> multimedia:libs has always been silly
> >>
> >> Once Packman packages weren't linked and that resulted in many
> >> problems with incompatible libraries and out of sync maintenance.
> >
> > I have no problem with linking, but link to the right thing for petes
> sake
> >
> > ffmpeg in Packman is linked to openSUSE.org:multimedia:libs
> >
> > This means it is version 3.0.2
> >
> > In Tumbleweed ffmpeg is 2.8.6
> >
> > In Leap ffmpeg is 2.8.6
> >
> > In Leap 42.2 ffmpeg is 2.8.6
> >
> > End result: Any Packman user is now forced to upgrade ffmpeg and
> > potentially ffmpeg related packages, including many multimedia
> > applications, to the versions in packman to a version of ffmpeg which
> > is UNTESTED and NOT SUPPORTED by the openSUSE Project (yet)
> ffmpeg is well tested upstream, I use the latest version on Leap and I
> use ffmpeg frequently.
> I have the ffmpeg libraries from both ffmpeg ABI 3 and 2 on my system,
> this is what the shared library policy is all about and the ffmpeg
> developers stick to the policy, ffmpeg libraries and gstreamer
> libraries are the keystone of linux multimedia.
>
You seem to forget the entire mess it created for Packman users when ffmpeg
3 became the "default" ffmpeg in Packman.
>
> > In short, this is dangerous, wrong, stupid and downright idiotic.. and
> > I'm being polite and holding back what i really think about it.
> >
> > At the very LEAST ffmpeg in Packman should be linked to
> Factory/Tumbleweed
>
> No, Packman users want the latest packages, Packman is the Tumbleweed
> of multimedia but it doesn't have automatic tests like Tumbleweed
> because it isn't an installation media it is a repository for packages
> that cannot be in the openSUSE distribution.
>
No, this is wrong.
A majority of packman users just want codecs and software which is not
available directly from openSUSE. This is mostly true for Leap users, maybe
a bit less
for TW users. Leap users values stability vs latest version of everything.
Pushing latest gstreamer stack or ffmpeg to Leap users through Packman is
simply wrong.
>
> > Packman for Leap should be linked to the version in Leap, so that
> > users do not have to suffer needless risk upgrading their packages.
> >
> >> Packman is a safe way for users to get the newest packages, especially
> >> Leap users because it rarely gets new packages. It's a pity somebody
> >> doesn't donate some extra server power to Packman to speed up the
> >> build cycle. Maintaining the Packman packages in multimedia apps and
> >> libs has taken away the old volatility that used to come from Packman.
> >> It's a far better option to enabling multiple obs repositories for Leap.
> >
> > No, Packman is not a safe way and this thread is sadly yet another
> > example of packman maintainers ignoring sound advice from seasoned
> > packagers who know what they're talking about.
>
> I actually don't agree with the zypper dup -r Packman model and would
> rather see a Requires: package-version-release model