Sorry, but I'm sad to read your answer ... You advocate abhorrent crutch
repeating over and over that the ball in front of us is cube ..
anyhow, thanks for all your activities for packman anyway, perhaps things
change one day. Maybe I should write some SDB article describing in-depth
what other
Thanks for your input ...
> What we used to do in the past is to add a "pm" suffix in the release
tag, e.g. ffmpeg-1.2.3-23.pm
this sounds good to me.
>> SUSEhelp on freenode knows this factoid:
>> ``zypper dup --from packman'' is wrong. It will forcefully
>> update _all_ packages that you
Am Fri, 17 Feb 2017 09:28:42 +0100
schrieb "sigsegv111 ." :
> >> SUSEhelp on freenode knows this factoid:
> >> ``zypper dup --from packman'' is wrong. It will
> >> forcefully update _all_ packages that you have already in your
> >> system with theirs packman instances
On Tue, Feb 07, Pascal Bleser wrote:
> Until zypper implements that behavior (which sounds like a very good
> idea to me), which won't be available until the next Leap to most
> users anyhow, the best approach is probably to do hard requires with
> version+release.
After reaching out to
It is indeed annoying because you end up with a setup that doesn't
play closed formats properly as it should be, with ffmpeg/libav
packages from different repositories. It also affects mplayer.
Until zypper implements that behavior (which sounds like a very good
idea to me), which won't be
On Tue, Feb 07, Daniel Pecka wrote:
> We were discussing this with olaf few weeks ago and I've suggested to
> ensure that proper libs from proper vendor are satisfied if you explicitely
> set your deps to be `= %version-%release' (eg they will require lib
> packages that have same version-release
Hello,
I've been solving in #suse in past weeks with several ppl same problem:
They had installed some package(s) from packman but its deps (usually
subpackages from same build) were from repo-oss .. Good example is ffmpeg,
which shall looks after the successful installation:
# rpm -qa