Re: [packman] dependencies of packman subpackages from same build

[Daniel Pecka]

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 alternatives than dup --from packman are available ...

best regards, daniel


S Pozdravem / Best Regards
---

Daniel Pecka - dpe...@opensuse.org
SCSA, SCNA, RHCE, CLP


On Fri, Feb 17, 2017 at 11:01 AM, Olaf Hering  wrote:

> 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 (if they exist), just
> > >> imagine ...
> > > Whoever put that there is overreacting.
> > > Please get this removed, it is wrong. Especially with 42.2 and
> > > Tumbleweed, they have very few overlapping packages.
> >
> > I have to repeat myself, this is not wrong, it's perfectly correct
> > and I've explicitely proven to olaf on freenode why ... If I do now
> > in my system zypper -vv dup --from packman it will simply said change
> > vendor (and update thus) of all packages that have in packman
> > instance to a packman version and this is really not what I want.
>
> This is fine for your own system, do whatever you want.
>
> The helptext above is most likely meant for other users, and they most
> likely do not care about your view at all. Instead they probably want
> something that works, which is 'zypper dup --from packman'.
>
> Olaf
>
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] dependencies of packman subpackages from same build

[sigsegv111 .]

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 have already in your system with theirs
>> packman instances (if they exist), just imagine ...

> Whoever put that there is overreacting.
> Please get this removed, it is wrong. Especially with 42.2 and
> Tumbleweed, they have very few overlapping packages.

I have to repeat myself, this is not wrong, it's perfectly correct and I've
explicitely proven to olaf on freenode why ... If I do now in my system
zypper -vv dup --from packman it will simply said change vendor (and update
thus) of all packages that have in packman instance to a packman version
and this is really not what I want. This is redundant, this is wrong, for
me it would be just a poor crutch to ensure, that ffmpeg and
gstreamer-plugins-bad subpackages come from same vendor. So changing vendor
for N other packages just because of this is an undesired and potentionally
dangerous side-effect. Check please attachments:

regards, daniel

On Tue, Feb 14, 2017 at 5:59 PM, Olaf Hering  wrote:

> 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 zypp-devel it seems libzypp has the info about
> vendor:src.rpm in the repo data, but it does not make use of it.
>
> I have modified the ffmpeg-2.8 and ffmpeg-3.2 packages and added
> hardcoded Requires, which covers SLE_12 and 42.1.
>
> > Another approach would be a pattern or an empty package
> > ("packman-ffmpeg") that just pulls everything of libav*/ffmpeg in with
> > hard requires -- that might sound crude but in the end, it is what
> > everyone wants if they add the Packman repos and want to install the
> > ffmpeg that's in there.
>
> How would that solve the interdependency issue? There is no easy way to
> refer to the packman build of a package. If the affected packages have
> to be touched anyway its probably easier to go with the hardcoding of
> Provides/Requires. Also its not so much about ffmpeg itself, but the
> libraries it provides to other packages.
>
>
> Olaf
>
> ___
> Packman mailing list
> Packman@links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
# zypper -vv se -is -r packman
Verbosity: 2
Initializing Target
Loading repository data...
Reading installed packages...
Force resolution: No

S | Name   | Type| Version  | Arch   | 
Repository
--++-+--++---
i | MPlayer| package | 1.2.r37916-1.1   | x86_64 | 
packman   
i | ffmpeg | package | 3.2-6.5  | x86_64 | 
packman   
i | gstreamer-plugins-bad  | package | 1.8.3-5.2| x86_64 | 
packman   
i | gstreamer-plugins-bad-lang | package | 1.8.3-5.2| noarch | 
packman   
i | libHalf12  | package | 2.2.0-37.4   | x86_64 | 
packman   
i | libIex-2_2-12  | package | 2.2.0-37.4   | x86_64 | 
packman   
i | libIlmThread-2_2-12| package | 2.2.0-37.4   | x86_64 | 
packman   
i | liba52-0   | package | 0.7.5+svn613-1.6 | x86_64 | 
packman   
i | libaudio2  | package | 1.9.4-1.6| x86_64 | 
packman   
i | libavcodec56   | package | 2.8.8-25.5   | x86_64 | 
packman   
i | libavcodec57   | package | 3.2-6.5  | x86_64 | 
packman   
i | libavdevice57  | package | 3.2-6.5  | x86_64 | 
packman   
i | libavfilter6   | package | 3.2-6.5  | x86_64 | 
packman   
i | libavformat56  | package | 2.8.8-25.5   | x86_64 | 
packman   
i | libavformat57  | package | 3.2-6.5  | x86_64 | 
packman   
i | libavresample3 | package | 3.2-6.5  | x86_64 | 
packman   
i | libavutil54| package | 2.8.8-25.5   | x86_64 | 
packman   
i | libavutil55| package | 3.2-6.5  | x86_64 | 
packman   
i | libdca0| package | 0.0.5-3.18   | x86_64 | 
packman   
i | libfaac0   | package | 1.28-9.6 | x86_64 | 
packman   
i | libfaad2   | package | 2.7-15.6 | x86_64 | 
packman   
i | libkcddb16 | package | 16.07.0-5.2  | x86_64 | 
packman   
i | libmad0| package | 0.15.1b-1.5  | x86_64 | 
packman   
i | libmp3lame0| package | 

Re: [packman] dependencies of packman subpackages from same build

[Olaf Hering]

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 (if they exist), just
> >> imagine ...  
> > Whoever put that there is overreacting.
> > Please get this removed, it is wrong. Especially with 42.2 and
> > Tumbleweed, they have very few overlapping packages.  
> 
> I have to repeat myself, this is not wrong, it's perfectly correct
> and I've explicitely proven to olaf on freenode why ... If I do now
> in my system zypper -vv dup --from packman it will simply said change
> vendor (and update thus) of all packages that have in packman
> instance to a packman version and this is really not what I want.

This is fine for your own system, do whatever you want.

The helptext above is most likely meant for other users, and they most
likely do not care about your view at all. Instead they probably want
something that works, which is 'zypper dup --from packman'.

Olaf


pgpVAWfZG_GYo.pgp
Description: Digitale Signatur von OpenPGP
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] dependencies of packman subpackages from same build

[Olaf Hering]

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 zypp-devel it seems libzypp has the info about
vendor:src.rpm in the repo data, but it does not make use of it.

I have modified the ffmpeg-2.8 and ffmpeg-3.2 packages and added
hardcoded Requires, which covers SLE_12 and 42.1.

> Another approach would be a pattern or an empty package
> ("packman-ffmpeg") that just pulls everything of libav*/ffmpeg in with
> hard requires -- that might sound crude but in the end, it is what
> everyone wants if they add the Packman repos and want to install the
> ffmpeg that's in there.

How would that solve the interdependency issue? There is no easy way to
refer to the packman build of a package. If the affected packages have
to be touched anyway its probably easier to go with the hardcoding of
Provides/Requires. Also its not so much about ffmpeg itself, but the
libraries it provides to other packages.


Olaf


signature.asc
Description: PGP signature
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] dependencies of packman subpackages from same build

[Pascal Bleser]

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 available until the next Leap to most
users anyhow, the best approach is probably to do hard requires with
version+release.

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

Might not be a bad idea to revive that for a few critical packages
(ffmpeg/libav definitely comes to mind) as it would make sure that we
would conflict release numbers with whatever is built in oss or in
multimedia:libs

Another approach would be a pattern or an empty package
("packman-ffmpeg") that just pulls everything of libav*/ffmpeg in with
hard requires -- that might sound crude but in the end, it is what
everyone wants if they add the Packman repos and want to install the
ffmpeg that's in there.

___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] dependencies of packman subpackages from same build

[Olaf Hering]

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 string) ..

Jan Engelhardt suggested that libzypp should make sure that each
subpackage comes from the same src.rpm. Its unclear if such info is in
the repo metadata. Making the change there would cover all cases.
I did not follow up on this with the zypp maintainers at
zypp-de...@opensuse.org.

My suggestion was to tweak the few affected packages (ffmpeg, gstreamer)
to make sure each subpkg comes from the same build.

> Current workaround in suse is, that ppl rely on the fact, that packman his

'zypper dup --from packman' is not a workaround.
It is the correct way to handle overlapping packages, not just for the
packman repository.

> 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 (if they exist), just imagine ...

Whoever put that there is overreacting.
Please get this removed, it is wrong. Especially with 42.2 and
Tumbleweed, they have very few overlapping packages.

Olaf


signature.asc
Description: PGP signature
___
Packman mailing list
Packman@links2linux.de
http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman