Re: directory deps
On 23-Mar-21 21:51, Elan Ruusamäe wrote: so, what could be done is fix that rpm4.16 buold will not generate deps for things unde: /usr/lib/.build-id/ In TLD I've simply set default of %_build_id_links macro to alldebug so regular packages are not cluttered with build-id stuff (it all goes to debuginfo packages). IMO easy and more flexible than hacking rpm to not generate deps. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
directory deps
looks like the directory deps in rpm5 pull superfluous packages when
installing:
libmount-2.36.2-2.x86_64 marks VirtualBox-6.1.18-4.x86_64 (cap
/usr/lib/.build-id/be)
libmount-2.36.2-2.x86_64: required "/usr/lib/.build-id/be" is provided
by the following packages:
a) OpenImageIO-plugin-dds-2.0.13-3.x86_64
b) abrt-libs-2.14.4-5.x86_64
c) dovecot-2.3.14-1.x86_64
d) frei0r-plugins-1.7.0-2.x86_64
e) gnumeric-1.12.48-4.x86_64
f) gstreamer-plugins-bad-1.16.2-5.x86_64
g) hfst-3.15.1-3.x86_64
h) libblockdev-2.25-2.x86_64
i) libproxy-0.4.17-2.x86_64
j) libreoffice-core-6.4.7.2-4.x86_64
k) libsolv-tools-0.7.17-2.x86_64
l) opencv-4.5.1-3.x86_64
m) python-cheetah-2.4.4-2.x86_64
n) python-dulwich-0.19.14-2.x86_64
o) python-pynifalcon-1.1-3.x86_64
p) python3-Crypto-2.6.1-12.x86_64
q) python3-LibAppArmor-3.0.1-2.x86_64
r) python3-bitarray-1.0.1-2.x86_64
t) python3-scipy-1.5.4-2.x86_64
s) samba-libs-4.13.3-4.x86_64
u) talloc-2.3.1-2.x86_64
v) util-linux-2.36.2-2.x86_64
w) util-vserver-0.30.216-1.pre3126.5.x86_64
x) vlc-3.0.12-2.x86_64
y) vtk-python3-8.2.0-5.x86_64
Which one do you want to install ('Q' to abort)?
so, what could be done is fix that rpm4.16 buold will not generate deps
for things unde:
/usr/lib/.build-id/
reproducer;
1 use this docker image:
registry.gitlab.com/pld-linux/pld@sha256:3bf9e65ba27f6d2e254d37e5219d5ff38b8e6f86c214ae0d8c730b2868775931
2. poldek -u php53-pecl-imagick -n th-ready -n th
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ImageMagick & php53-pecl-imagick
On 23.03.2021 20:45, Wojciech Błaszkowski wrote: Hello, some unresolved dependencies with ImageMagick & php53 had occured. Any chance to fix that? # poldek --upa && poldek -ug ImageMagick th is up to date th is up to date Loading [pndir]th... Loading [pndir]th... 30218 packages read Processing dependencies... ImageMagick-7.0.10.35-1.x86_64 obsoleted by ImageMagick-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved ImageMagick = 1:7.0.10.35-1) ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 marks ImageMagick-libs-7.0.10.60-1.x86_64 (cap libMagickCore-7.Q16.so.8()(64bit)) ImageMagick-libs-7.0.10.35-1.x86_64 obsoleted by ImageMagick-libs-7.0.10.60-1.x86_64 error: libMagickCore-7.Q16.so.7()(64bit) is required by installed php53-pecl-imagick-3.4.4-3.x86_64 this just means the package was removed: - http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2021-February/026147.html and the rebuild is not yet moved to main $ docker-run registry.gitlab.com/pld-linux/pld Unable to find image 'registry.gitlab.com/pld-linux/pld:latest' locally latest: Pulling from pld-linux/pld 8b782821df9b: Pull complete Digest: sha256:3bf9e65ba27f6d2e254d37e5219d5ff38b8e6f86c214ae0d8c730b2868775931 Status: Downloaded newer image for registry.gitlab.com/pld-linux/pld:latest [@3cbca0a58712 /]# poldek -u php53-pecl-imagick th::packages.ndir.gz [17.8M (6.7M/s)] th::packages.ndir.dscr.gz [1.2M (1.2M/s)] th::packages.ndir.gz [17.8M (13.4M/s)] th::packages.ndir.dscr.gz [2.3M (1.0M/s)] Loading [pndir]th... Creating directory index of th... Loading [pndir]th... Creating directory index of th... 30218 packages read error: php53-pecl-imagick: no such package [@3cbca0a58712 /]# [@3cbca0a58712 /]# poldek -u php53-pecl-imagick -n th-ready -n th th-ready::packages.ndir.gz [5.4M (5.4M/s)] th-ready::packages.ndir.dscr.gz [241.1K (241.1K/s)] th-ready::packages.ndir.gz [4.1M (4.1M/s)] th-ready::packages.ndir.dscr.gz [251.0K (251.0K/s)] Loading [pndir]th-ready... Creating directory index of th-ready... Loading [pndir]th-ready... Creating directory index of th-ready... Loading [pndir]th... Loading [pndir]th... 34486 packages read Processing dependencies... php53-pecl-imagick-3.4.4-6.x86_64 marks php53-common-5.3.29-52.x86_64 (cap /etc/php53/conf.d) php53-common-5.3.29-52.x86_64 marks php-dirs-1.10-1.noarch (cap php-dirs >= 1.4) ... ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ImageMagick & php53-pecl-imagick
Hello, some unresolved dependencies with ImageMagick & php53 had occured. Any chance to fix that? # poldek --upa && poldek -ug ImageMagick th is up to date th is up to date Loading [pndir]th... Loading [pndir]th... 30218 packages read Processing dependencies... ImageMagick-7.0.10.35-1.x86_64 obsoleted by ImageMagick-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved ImageMagick = 1:7.0.10.35-1) ImageMagick-coder-jpeg-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 ImageMagick-coder-jpeg-7.0.10.60-1.x86_64 marks ImageMagick-libs-7.0.10.60-1.x86_64 (cap libMagickCore-7.Q16.so.8()(64bit)) ImageMagick-libs-7.0.10.35-1.x86_64 obsoleted by ImageMagick-libs-7.0.10.60-1.x86_64 error: libMagickCore-7.Q16.so.7()(64bit) is required by installed php53-pecl-imagick-3.4.4-3.x86_64 error: libMagickWand-7.Q16.so.7()(64bit) is required by installed php53-pecl-imagick-3.4.4-3.x86_64 error: libMagickWand-7.Q16.so.7(VERS_7.0)(64bit) is required by installed php53-pecl-imagick-3.4.4-3.x86_64 greedy upgrade ImageMagick-coder-png-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-png-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-png-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-tiff-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-tiff-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-tiff-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-pdf-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-pdf-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-pdf-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-jbig-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-jbig-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-jbig-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-jpeg2-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-jpeg2-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-jpeg2-7.0.10.60-1.x86_64 greedy upgrade ImageMagick-coder-heic-7.0.10.35-1.x86_64 to 7.0.10.60-1.x86_64 (unresolved libMagickCore-7.Q16.so.7()(64bit)) ImageMagick-coder-heic-7.0.10.35-1.x86_64 obsoleted by ImageMagick-coder-heic-7.0.10.60-1.x86_64 There are 9 packages to install (8 marked by dependencies), 9 to remove: U ImageMagick-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-coder-heic-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-coder-jbig-(7.0.10.35 => 7.0.10.60)-1.x86_64 U ImageMagick-coder-jpeg-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-coder-jpeg2-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-coder-pdf-(7.0.10.35 => 7.0.10.60)-1.x86_64 U ImageMagick-coder-png-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-coder-tiff-(7.0.10.35 => 7.0.10.60)-1.x86_64 ImageMagick-libs-(7.0.10.35 => 7.0.10.60)-1.x86_64 This operation will use 122.1KB of disk space. Need to get 2.1MB of archives (2.1MB to download). error: 3 unresolved dependencies -- Pozdrawiam, Wojciech Błaszkowski www.blaszkowski.com, +48.600197207 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 12:27 PM Jakub Bogusz wrote: > > On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote: > > On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > > > > > > > On 23.03.2021 12:59, Neal Gompa wrote: > > > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe > > > > wrote: > > > >> i found some odd inconsistency: > > > >> > > > >> > > > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > > > >> virtual(init-daemon) > > > >> error: line 319: Only package names are allowed in Obsoletes: > > > >> Obsoletes:virtual(init-daemon) > > > >> > > > >> > > > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on > > > >> some > > > >> other tags; > > > >> > > > >> > > > >> Requires: webserver(indexfile) > > > >> Requires: webserver(php) >= 4.2.0 > > > >> Suggests: php(openssl) > > > >> Suggests: webserver(setenv) > > > >> Provides: group(eventum) > > > >> Provides: user(eventum) > > > >> > > > > Obsoletes has to be a real package name, but virtual names are allowed > > > > for other tags. > > > Why? > > > > This was always the case in RPM, but it started enforcing it in RPM > > > > 4.13. > > > > > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > > > > > and we are using it when multiple packages provide something common, say: > > > > > > 'init-daemon" > > > > > > they are mutually exclusive, so installing one, must uninstall the other. > > > > > > and if adding new "virtual(init-daemon)" virtual, without need to update > > > other packages, they all can have O/P: virtual(init-daemon) > > > > > > > > > now rpm enforces that each of those packages must cross reference all > > > 'the other' virtuals... duh! > > > > > > > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. > > > > For example, the following is enough to get the behavior you want: > > > > Provides: init-daemon > > Conflicts: init-daemon > > Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package > management software, thus making package non-installable... > > Does it have well defined semantics now? > Hmm, actually I was wrong, it was done in RPM 4.9.0: https://rpm.org/wiki/Releases/4.9.0 As for "well-defined semantics", it's basically this mailing list post: http://lists.rpm.org/pipermail/rpm-maint/2010-April/002719.html It generally works for me, though admittedly, I've only tested YUM, DNF, and Zypper. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote: > On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > > > > On 23.03.2021 12:59, Neal Gompa wrote: > > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > > >> i found some odd inconsistency: > > >> > > >> > > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > > >> virtual(init-daemon) > > >> error: line 319: Only package names are allowed in Obsoletes: > > >> Obsoletes:virtual(init-daemon) > > >> > > >> > > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > > >> other tags; > > >> > > >> > > >> Requires: webserver(indexfile) > > >> Requires: webserver(php) >= 4.2.0 > > >> Suggests: php(openssl) > > >> Suggests: webserver(setenv) > > >> Provides: group(eventum) > > >> Provides: user(eventum) > > >> > > > Obsoletes has to be a real package name, but virtual names are allowed > > > for other tags. > > Why? > > > This was always the case in RPM, but it started enforcing it in RPM 4.13. > > > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > > > and we are using it when multiple packages provide something common, say: > > > > 'init-daemon" > > > > they are mutually exclusive, so installing one, must uninstall the other. > > > > and if adding new "virtual(init-daemon)" virtual, without need to update > > other packages, they all can have O/P: virtual(init-daemon) > > > > > > now rpm enforces that each of those packages must cross reference all > > 'the other' virtuals... duh! > > > > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. > > For example, the following is enough to get the behavior you want: > > Provides: init-daemon > Conflicts: init-daemon Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package management software, thus making package non-installable... Does it have well defined semantics now? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > On 23.03.2021 12:59, Neal Gompa wrote: > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > >> i found some odd inconsistency: > >> > >> > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > >> virtual(init-daemon) > >> error: line 319: Only package names are allowed in Obsoletes: > >> Obsoletes:virtual(init-daemon) > >> > >> > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > >> other tags; > >> > >> > >> Requires: webserver(indexfile) > >> Requires: webserver(php) >= 4.2.0 > >> Suggests: php(openssl) > >> Suggests: webserver(setenv) > >> Provides: group(eventum) > >> Provides: user(eventum) > >> > > Obsoletes has to be a real package name, but virtual names are allowed > > for other tags. > Why? > > This was always the case in RPM, but it started enforcing it in RPM 4.13. > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > and we are using it when multiple packages provide something common, say: > > 'init-daemon" > > they are mutually exclusive, so installing one, must uninstall the other. > > and if adding new "virtual(init-daemon)" virtual, without need to update > other packages, they all can have O/P: virtual(init-daemon) > > > now rpm enforces that each of those packages must cross reference all > 'the other' virtuals... duh! > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. For example, the following is enough to get the behavior you want: Provides: init-daemon Conflicts: init-daemon -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On 23.03.2021 12:59, Neal Gompa wrote: On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: i found some odd inconsistency: error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon) error: line 319: Only package names are allowed in Obsoletes: Obsoletes:virtual(init-daemon) So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some other tags; Requires: webserver(indexfile) Requires: webserver(php) >= 4.2.0 Suggests: php(openssl) Suggests: webserver(setenv) Provides: group(eventum) Provides: user(eventum) Obsoletes has to be a real package name, but virtual names are allowed for other tags. Why? This was always the case in RPM, but it started enforcing it in RPM 4.13. PLD has used virtual obsoletes for the time i've used it (since 2004). and we are using it when multiple packages provide something common, say: 'init-daemon" they are mutually exclusive, so installing one, must uninstall the other. and if adding new "virtual(init-daemon)" virtual, without need to update other packages, they all can have O/P: virtual(init-daemon) now rpm enforces that each of those packages must cross reference all 'the other' virtuals... duh! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - x32 patch fixes
On 23.03.2021 14:44, Jan Rękorajski wrote:
> On Tue, Mar 23, 2021 at 1:59 PM Jan Palus wrote:
>
> > On 23.03.2021 08:53, baggins wrote:
> > > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > > Author: Jan Rękorajski
> > > Date: Tue Mar 23 08:52:27 2021 +0100
> > >
> > > - x32 patch fixes
> > >
> > > x32.patch | 10 +++---
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > > ---
> > > diff --git a/x32.patch b/x32.patch
> > > index 38aa140..f7ab616 100644
> > > --- a/x32.patch
> > > +++ b/x32.patch
> > > -@@ -190,10 +201,14 @@
> > > - # skip architectures for which we dont have full config parameters
> > > - [ -z "$CANONARCH" ] && continue
> > > -
> > > -- if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > > -+ if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > > +@@ -190,6 +201,10 @@
> > > LIB=${LIB}64
> > > fi
> >
> > This hunk should either be brought back or CANONCOLOR for x86_64 should
> > be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
> >
>
> Can you restore this hunk and rebuild rpm? I can't do it till evening :(
>
> It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
> "x86_64"] || [ "$CANONCOLOR" = 3 ]; then'
Done. Looks like everything is back to normal.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - x32 patch fixes
On Tue, Mar 23, 2021 at 1:59 PM Jan Palus wrote:
> On 23.03.2021 08:53, baggins wrote:
> > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > Author: Jan Rękorajski
> > Date: Tue Mar 23 08:52:27 2021 +0100
> >
> > - x32 patch fixes
> >
> > x32.patch | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> > ---
> > diff --git a/x32.patch b/x32.patch
> > index 38aa140..f7ab616 100644
> > --- a/x32.patch
> > +++ b/x32.patch
> > -@@ -190,10 +201,14 @@
> > - # skip architectures for which we dont have full config parameters
> > - [ -z "$CANONARCH" ] && continue
> > -
> > -- if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > -+ if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > +@@ -190,6 +201,10 @@
> > LIB=${LIB}64
> > fi
>
> This hunk should either be brought back or CANONCOLOR for x86_64 should
> be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
>
Can you restore this hunk and rebuild rpm? I can't do it till evening :(
It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
"x86_64"] || [ "$CANONCOLOR" = 3 ]; then'
--
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/rpm] - x32 patch fixes
On 23.03.2021 08:53, baggins wrote:
> commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> Author: Jan Rękorajski
> Date: Tue Mar 23 08:52:27 2021 +0100
>
> - x32 patch fixes
>
> x32.patch | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
> ---
> diff --git a/x32.patch b/x32.patch
> index 38aa140..f7ab616 100644
> --- a/x32.patch
> +++ b/x32.patch
> -@@ -190,10 +201,14 @@
> - # skip architectures for which we dont have full config parameters
> - [ -z "$CANONARCH" ] && continue
> -
> -- if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> -+ if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> +@@ -190,6 +201,10 @@
> LIB=${LIB}64
> fi
This hunk should either be brought back or CANONCOLOR for x86_64 should
be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > > i found some odd inconsistency: > > > error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon) > error: line 319: Only package names are allowed in Obsoletes: > Obsoletes:virtual(init-daemon) > > > So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > other tags; > > > Requires: webserver(indexfile) > Requires: webserver(php) >= 4.2.0 > Suggests: php(openssl) > Suggests: webserver(setenv) > Provides: group(eventum) > Provides: user(eventum) > Obsoletes has to be a real package name, but virtual names are allowed for other tags. This was always the case in RPM, but it started enforcing it in RPM 4.13. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
package names in dependencies
i found some odd inconsistency: error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon) error: line 319: Only package names are allowed in Obsoletes: Obsoletes: virtual(init-daemon) So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some other tags; Requires: webserver(indexfile) Requires: webserver(php) >= 4.2.0 Suggests: php(openssl) Suggests: webserver(setenv) Provides: group(eventum) Provides: user(eventum) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
