-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts? - -- - -Igor Gnatenko
On Thu, Jan 18, 2018 at 4:50 PM, Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
Actually, libsolv doesn't quite do this all the time in every case. There were a few fixes to libsolv post 0.6.30 for handling more conditions of it.
It also avoids weird situations where you get arch switching with package splits and obsoletes...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thu, 2018-01-18 at 16:58 -0500, Neal Gompa wrote:
On Thu, Jan 18, 2018 at 4:50 PM, Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
Actually, libsolv doesn't quite do this all the time in every case. There were a few fixes to libsolv post 0.6.30 for handling more conditions of it.
It also avoids weird situations where you get arch switching with package splits and obsoletes...
There are flags related to coloring Obsoletes, so that should be fine.
But it seems that if I run $ sudo dnf install wine -x libatomic.x86_64, it would happily install without it, but on next upgrade -- pull it in..
So it seems that we still need to use %{?_isa}.
Michael, can you give a hint whether we need to use it for weak deps as well? If so -- in which parts of conditions? - -- - -Igor Gnatenko
On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
Huh? You can't be serious. I've been keeping a 32bit-only set of wine packages on my machine for quite some time and I'd be quite annoyed if I suddenly had to install all corresponding 64bit ones, too.
When did you implement this change and for which Fedora release? Could you point to its announcement?
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
The reason is to ensure 64bit subpackages dependency on main package won't be satisfied by a 32bit counterpart and vice-versa. This has always been the case.
Regards, Dominik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thu, 2018-01-18 at 23:04 +0100, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
Huh? You can't be serious. I've been keeping a 32bit-only set of wine packages on my machine for quite some time and I'd be quite annoyed if I suddenly had to install all corresponding 64bit ones, too.
Well, I am pretty serious. I think you just didn't notice all those 64bit packages because you had them already installed.
$ sudo dnf install wine […] libatomic i686 7.2.1-6.fc28 rawhide 40 k libatomic x86_64 7.2.1-6.fc28 rawhide 40 k […]
When did you implement this change and for which Fedora release?
Since DNF was implemented?
Could you point to its announcement?
Well, this particular thing was never discussed (at least to my knowledge).
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
The reason is to ensure 64bit subpackages dependency on main package won't be satisfied by a 32bit counterpart and vice-versa. This has always been the case.
Except that 64bit package is always pulled in → no need for pulling 32bit package. Yeah, requiring 32bit package from 64bit one (aka wine) is different case (it doesn't really use %{?_isa}) and is valid one. - -- - -Igor Gnatenko
On Thursday, 18 January 2018 at 23:20, Igor Gnatenko wrote:
On Thu, 2018-01-18 at 23:04 +0100, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
Huh? You can't be serious. I've been keeping a 32bit-only set of wine packages on my machine for quite some time and I'd be quite annoyed if I suddenly had to install all corresponding 64bit ones, too.
Well, I am pretty serious. I think you just didn't notice all those 64bit packages because you had them already installed.
$ sudo dnf install wine [â¦] libatomic i686 7.2.1-6.fc28 rawhide 40 k libatomic x86_64 7.2.1-6.fc28 rawhide 40 k [â¦]
Wrong. I keep close watch on what packages I have installed. I only have 32bit wine installed at the moment, so your statement seems untrue: $ rpm -qa wine* |grep i686 |wc -l 3 $ rpm -qa wine* |grep x86_64 |wc -l 0
When did you implement this change and for which Fedora release?
Since DNF was implemented?
Apparently it's not implemented like you described.
[...]
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
The reason is to ensure 64bit subpackages dependency on main package won't be satisfied by a 32bit counterpart and vice-versa. This has always been the case.
Except that 64bit package is always pulled in â no need for pulling 32bit package. Yeah, requiring 32bit package from 64bit one (aka wine) is different case (it doesn't really use %{?_isa}) and is valid one.
I never said anything about cross-bitness requirements. You misunderstood. And I've just demonstrated that dnf doesn't always pull in 64bit package when 32bit counterpart is being installed.
Regards, Dominik
Igor Gnatenko wrote:
Yeah, requiring 32bit package from 64bit one (aka wine) is different case (it doesn't really use %{?_isa}) and is valid one.
By the way, is that even still needed? A lot of Windows software is now native Win64. Is a 64-bit-only WINE really still not workable?
Kevin Kofler
On 01/18/2018 06:41 PM, Kevin Kofler wrote:
By the way, is that even still needed? A lot of Windows software is now native Win64. Is a 64-bit-only WINE really still not workable?
Yes. Yes. There are cases where the 64-bit binary doesn't run and the 32-bit one does. There are cases where the software is 32-bit only and no longer supported but still needed to export data.
Until Microsoft decides to abandon 32-bit we will still need it.
19.01.2018 04:54 Michael Cronenworth mike@cchtml.com wrote:
[...] Yes. Yes. There are cases where the 64-bit binary doesn't run and the 32-bit one does. There are cases where the software is 32-bit only and no longer supported but still needed to export data.
Until Microsoft decides to abandon 32-bit we will still need it.
Working with Windows developers (developing applications for Windows, not Windows itself :-) ) I must confirm that 32-bit applications for Windows are still pretty common. Because "why should we rebuild our binaries for 64 bits if 32-bit binaries work everywhere while 64-bit ones not necessarily."
Regards,
Rafal
Michael Cronenworth wrote:
Yes. Yes. There are cases where the 64-bit binary doesn't run and the 32-bit one does. There are cases where the software is 32-bit only and no longer supported but still needed to export data.
Until Microsoft decides to abandon 32-bit we will still need it.
I'm not saying that 32-bit WINE should go away nor that the 64-bit repository should not include it as a multilib package. I'm saying that installing WINE on an x86_64 system should not force you to install the 32- bit multilib version.
Kevin Kofler
On 01/19/2018 05:22 AM, Kevin Kofler wrote:
I'm not saying that 32-bit WINE should go away nor that the 64-bit repository should not include it as a multilib package. I'm saying that installing WINE on an x86_64 system should not force you to install the 32- bit multilib version.
You can use 64-bit wine by itself today. The "wine" meta package is a catch-all, get it all installed for most cases, kind of package. Remove the meta package and then you can remove all the 32-bit packages.
Igor Gnatenko wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Does anybody know why we are still using %{?_isa} thing?
To ensure arch's match between subpkgs.
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
I can dnf install <foo>.i686
and I see no 64bit packages pulled in.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
See above, imo, no, not wise to drop it.
-- Rex
On Friday, 19 January 2018 at 04:16, Michael Schwendt wrote:
On Thu, 18 Jan 2018 20:07:27 -0600, Rex Dieter wrote:
I can dnf install <foo>.i686
and I see no 64bit packages pulled in.
With F27,
dnf install wine.i686
really pulls in various x86_64 alongside their i686 builds.
Not if you disable processing weak dependencies or use -x to exclude them. I expect that scenario to keep working.
Regards, Dominik
Michael Schwendt wrote:
On Thu, 18 Jan 2018 20:07:27 -0600, Rex Dieter wrote:
I can dnf install <foo>.i686
and I see no 64bit packages pulled in.
With F27,
dnf install wine.i686
really pulls in various x86_64 alongside their i686 builds.
wine is an exception, it does some... interesting things dependency-wise.
-- rex
On 19 January 2018 at 03:16, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 18 Jan 2018 20:07:27 -0600, Rex Dieter wrote:
I can dnf install <foo>.i686
and I see no 64bit packages pulled in.
With F27,
dnf install wine.i686
wine is completely brain damaged example. Doesn't matter wine.i686 or x86_64 both packages have both arch dependencies. on both arch these two packages are *EMPTY* and have static set of dependencies which is causing install both archs other packages.
$ dnf download wine.i686 $ rpm -qp --qf '[%{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]' wine-2.20-1.fc28.i686.rpm /usr/bin/ntlm_auth mesa-dri-drivers(x86-32) mingw32-wine-gecko = 2.47 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 wine-capi(x86-32) = 2.20-1.fc28 wine-cms(x86-32) = 2.20-1.fc28 wine-common = 2.20-1.fc28 wine-core(x86-32) = 2.20-1.fc28 wine-desktop = 2.20-1.fc28 wine-fonts = 2.20-1.fc28 wine-ldap(x86-32) = 2.20-1.fc28 wine-mono = 4.7.1 wine-openal(x86-32) = 2.20-1.fc28 wine-opencl(x86-32) = 2.20-1.fc28 wine-pulseaudio(x86-32) = 2.20-1.fc28 wine-twain(x86-32) = 2.20-1.fc28 $ rpm -qp -l wine-2.20-1.fc28.i686.rpm (contains no files) $
It is easy way to install only one ABI version wine package. Just install wine with all dependencies, then remove wine as package and it will be possible to remove all secondary ABI version packages.
IMHO wine as the package is broken by design. Maintainer of the wine just over complicated almost everything what was possible to over complicate.
kloczek
On 01/19/2018 09:32 AM, Tomasz Kłoczko wrote:
IMHO wine as the package is broken by design. Maintainer of the wine just over complicated almost everything what was possible to over complicate.
It's not broken. It's just the nature of Windows binaries. Users expect "dnf install wine" to install everything they need to run their .exe file. I don't see any benefit of removing the 32-bit packages from being installed. It would add another command users have to run.
On 19 January 2018 at 15:48, Michael Cronenworth mike@cchtml.com wrote:
On 01/19/2018 09:32 AM, Tomasz Kłoczko wrote:
IMHO wine as the package is broken by design. Maintainer of the wine just over complicated almost everything what was possible to over complicate.
It's not broken. It's just the nature of Windows binaries. Users expect "dnf install wine" to install everything they need to run their .exe file. I don't see any benefit of removing the 32-bit packages from being installed. It would add another command users have to run.
So you want to say that it is not possible to have cleanly separated ABI versions in rpm packaged form? Whoever will be trying to install wine blindly on i686 or x86_64 only systems will stump in this landmine. If someone will install let's say 64 bit wine and will be trying execute 32 bit windows binary will have install message about lack of ABI support and after some face palm will consider to install 32 bit packages. When my intention was to try run iTunes I was curious "why the h*ll wine drags both ABIs packages?" It took me significant time after looking on wine.spec to decipher that these dependencies are artificial and trying to use 64 bit iTunes I don't need all this stuff.
If you are still thinking that current wine packaging model is OK just thy to answer on the question: why there are wine.i686 and wine.x8_64?
Nevertheless this has nothing to do with subject.
kloczek
On Fri, 19 Jan 2018 15:32:13 +0000, Tomasz Kłoczko wrote:
dnf install wine.i686
wine is completely brain damaged example.
Maybe. Something on x86_64 is broken nevertheless. If memory serves correctly, Yum could handle it, but dnf seems to run into non-arch-specific explicit dependencies (i.e. ancient non-%_isa Requires on -devel packages) and pulls in only the packages for the primary arch:
# dnf install audacious-devel.i686 Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: audacious-devel i686 3.9-1.fc27 fedora 68 k Installing dependencies: atk i686 2.26.1-1.fc27 updates 271 k atk-devel x86_64 2.26.1-1.fc27 updates 190 k audacious-libs i686 3.9-1.fc27 fedora 326 k avahi-libs i686 0.7-3.fc27 fedora 61 k bzip2-devel x86_64 1.0.6-24.fc27 fedora 223 k bzip2-libs i686 1.0.6-24.fc27 fedora 45 k cairo i686 1.15.10-1.fc27 updates 752 k cairo-devel x86_64 1.15.10-1.fc27 updates 262 k cups-libs i686 1:2.2.4-8.fc27 updates 434 k dbus-libs i686 1:1.12.0-1.fc27 updates 187 k elfutils-libelf i686 0.170-1.fc27 fedora 212 k expat i686 2.2.5-1.fc27 updates 103 k expat-devel x86_64 2.2.5-1.fc27 updates 54 k fontconfig i686 2.12.6-4.fc27 updates 259 k fontconfig-devel x86_64 2.12.6-4.fc27 updates 139 k freetype i686 2.8-7.fc27 updates 391 k freetype-devel x86_64 2.8-7.fc27 updates 452 k gdk-pixbuf2 i686 2.36.11-1.fc27 fedora 470 k gdk-pixbuf2-devel x86_64 2.36.11-1.fc27 fedora 222 k gdk-pixbuf2-modules i686 2.36.11-1.fc27 fedora 107 k glib2 i686 2.54.2-1.fc27 updates 2.5 M glib2-devel i686 2.54.2-1.fc27 updates 453 k glib2-devel x86_64 2.54.2-1.fc27 updates 453 k glibc i686 2.26-21.fc27 updates 4.5 M gmp i686 1:6.1.2-6.fc27 fedora 276 k gnutls i686 3.5.16-4.fc27 updates 763 k graphite2 i686 1.3.10-3.fc27 fedora 123 k graphite2-devel x86_64 1.3.10-3.fc27 fedora 43 k gtk2 i686 2.24.32-1.fc27 updates 3.5 M gtk2-devel i686 2.24.32-1.fc27 updates 3.0 M gtk2-devel x86_64 2.24.32-1.fc27 updates 3.0 M harfbuzz i686 1.4.8-1.fc27 fedora 266 k harfbuzz-devel x86_64 1.4.8-1.fc27 fedora 160 k jasper-libs i686 2.0.14-1.fc27 fedora 166 k jbigkit-libs i686 2.1-8.fc27 fedora 52 k keyutils-libs i686 1.5.10-3.fc27 fedora 32 k krb5-libs i686 1.15.2-4.fc27 updates 846 k libICE i686 1.0.9-11.fc27 fedora 72 k libSM i686 1.2.2-7.fc27 fedora 44 k libX11 i686 1.6.5-4.fc27 fedora 638 k libX11-devel x86_64 1.6.5-4.fc27 fedora 984 k libX11-xcb i686 1.6.5-4.fc27 fedora 22 k libXau i686 1.0.8-9.fc27 fedora 34 k libXau-devel x86_64 1.0.8-9.fc27 fedora 18 k libXcomposite i686 0.4.4-11.fc27 fedora 27 k libXcomposite-devel x86_64 0.4.4-11.fc27 fedora 20 k libXcursor i686 1.1.14-10.fc27 fedora 35 k libXcursor-devel x86_64 1.1.14-10.fc27 fedora 27 k libXdamage i686 1.1.4-11.fc27 fedora 25 k libXext i686 1.3.3-7.fc27 fedora 45 k libXext-devel x86_64 1.3.3-7.fc27 fedora 79 k libXfixes i686 5.0.3-4.fc27 fedora 23 k libXfixes-devel x86_64 5.0.3-4.fc27 fedora 17 k libXft i686 2.3.2-7.fc27 fedora 64 k libXft-devel x86_64 2.3.2-7.fc27 fedora 23 k libXi i686 1.7.9-4.fc27 fedora 48 k libXi-devel x86_64 1.7.9-4.fc27 fedora 109 k libXinerama i686 1.1.3-9.fc27 fedora 18 k libXinerama-devel x86_64 1.1.3-9.fc27 fedora 17 k libXrandr i686 1.5.1-4.fc27 fedora 32 k libXrandr-devel x86_64 1.5.1-4.fc27 fedora 25 k libXrender i686 0.9.10-4.fc27 fedora 32 k libXrender-devel x86_64 0.9.10-4.fc27 fedora 21 k libXxf86vm i686 1.1.4-6.fc27 fedora 23 k libblkid i686 2.30.2-1.fc27 fedora 208 k libcom_err i686 1.43.5-2.fc27 fedora 46 k libcrypt-nss i686 2.26-21.fc27 updates 39 k libdatrie i686 0.2.9-6.fc27 fedora 32 k libdrm i686 2.4.89-1.fc27 updates 175 k libevdev i686 1.5.7-3.fc27 fedora 39 k libffi i686 3.1-14.fc27 fedora 34 k libgcc i686 7.2.1-2.fc27 fedora 98 k libgcrypt i686 1.8.1-3.fc27 updates 431 k libglvnd i686 1:1.0.0-1.fc27 updates 86 k libglvnd-egl i686 1:1.0.0-1.fc27 updates 48 k libglvnd-glx i686 1:1.0.0-1.fc27 updates 122 k libgpg-error i686 1.27-3.fc27 fedora 186 k libgudev i686 232-1.fc27 fedora 32 k libicu i686 57.1-9.fc27 updates 8.5 M libicu-devel x86_64 57.1-9.fc27 updates 915 k libidn2 i686 2.0.4-1.fc27 fedora 99 k libinput i686 1.9.3-2.fc27 updates 160 k libjpeg-turbo i686 1.5.3-1.fc27 updates 163 k libmount i686 2.30.2-1.fc27 fedora 225 k libpciaccess i686 0.13.4-6.fc27 fedora 32 k libpng i686 2:1.6.31-1.fc27 fedora 130 k libpng-devel x86_64 2:1.6.31-1.fc27 fedora 323 k libselinux i686 2.7-3.fc27 updates 177 k libsepol i686 2.7-2.fc27 updates 346 k libstdc++ i686 7.2.1-2.fc27 fedora 497 k libtasn1 i686 4.12-3.fc27 fedora 76 k libthai i686 0.1.25-4.fc27 fedora 199 k libtiff i686 4.0.9-2.fc27 updates 192 k libunistring i686 0.9.7-3.fc27 fedora 418 k libuuid i686 2.30.2-1.fc27 fedora 83 k libverto i686 0.2.6-11.fc27 fedora 21 k libwacom i686 0.26-1.fc27 fedora 37 k libwayland-client i686 1.14.0-2.fc27 updates 36 k libwayland-server i686 1.14.0-2.fc27 updates 43 k libxcb i686 1.12-5.fc27 fedora 246 k libxcb-devel x86_64 1.12-5.fc27 fedora 1.0 M libxkbcommon i686 0.7.1-5.fc27 fedora 117 k libxkbcommon-x11 i686 0.7.1-5.fc27 fedora 24 k libxshmfence i686 1.2-6.fc27 fedora 12 k lz4-libs i686 1.8.0-1.fc27 fedora 52 k mesa-libEGL i686 17.2.4-3.fc27 updates 118 k mesa-libGL i686 17.2.4-3.fc27 updates 193 k mesa-libgbm i686 17.2.4-3.fc27 updates 50 k mesa-libglapi i686 17.2.4-3.fc27 updates 67 k mtdev i686 1.1.5-9.fc27 fedora 22 k nettle i686 3.4-1.fc27 updates 314 k nss-softokn-freebl i686 3.34.0-1.0.fc27 updates 238 k openssl-libs i686 1:1.1.0g-1.fc27 updates 1.2 M p11-kit i686 0.23.9-2.fc27 updates 259 k pango i686 1.40.14-1.fc27 updates 300 k pango-devel x86_64 1.40.14-1.fc27 updates 318 k pcre i686 8.41-4.fc27 updates 206 k pcre-cpp x86_64 8.41-4.fc27 updates 42 k pcre-devel x86_64 8.41-4.fc27 updates 549 k pcre-utf16 x86_64 8.41-4.fc27 updates 191 k pcre-utf32 x86_64 8.41-4.fc27 updates 181 k pcre2 i686 10.30-5.fc27 updates 238 k pcre2-utf16 i686 10.30-5.fc27 updates 218 k pixman i686 0.34.0-4.fc27 fedora 264 k pixman-devel x86_64 0.34.0-4.fc27 fedora 18 k qt5-qtbase i686 5.9.2-6.fc27 updates 3.6 M qt5-qtbase-gui i686 5.9.2-6.fc27 updates 5.6 M sqlite-libs i686 3.20.1-1.fc27 fedora 569 k systemd-libs i686 234-9.fc27 updates 497 k xcb-util i686 0.4.0-8.fc27 fedora 20 k xcb-util-image i686 0.4.0-8.fc27 fedora 20 k xcb-util-keysyms i686 0.4.0-6.fc27 fedora 15 k xcb-util-renderutil i686 0.3.9-9.fc27 fedora 18 k xcb-util-wm i686 0.4.1-11.fc27 fedora 33 k xorg-x11-proto-devel noarch 7.7-23.fc27 fedora 287 k xz-libs i686 5.2.3-4.fc27 fedora 99 k zlib i686 1.2.11-4.fc27 fedora 102 k zlib-devel x86_64 1.2.11-4.fc27 fedora 56 k
Transaction Summary ================================================================================ Install 139 Packages
Total size: 59 M Total download size: 58 M Installed size: 215 M
On Thu, 2018-01-18 at 20:07 -0600, Rex Dieter wrote:
Igor Gnatenko wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Does anybody know why we are still using %{?_isa} thing?
To ensure arch's match between subpkgs.
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
I can dnf install <foo>.i686
and I see no 64bit packages pulled in.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
See above, imo, no, not wise to drop it.
+1 for multilib packages is important
On 01/18/2018 11:50 PM, Igor Gnatenko wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
Does anybody know why we are still using %{?_isa} thing?
DNF/libsolv forcefully install 64bit package for any 32bit package in transaction. So it is not possible to get 32bit package without 64bit counterpart.
So then what's the reason of using %{?_isa}? Just some old cruft from yum era? Can we drop it? Thoughts?
%{_isa} is there to express very real dependencies where plain NEVR is ambiguous and insufficient. Just because dnf/libsolv/yum whatever might do the right thing by heuristics when installing doesn't mean the dependency is not there (think 'rpm -e <pkg>' for one)
Also history has shown over and over again that depsolver heuristics get confused with multilib'ed package splits and things like partial push with missing multilib arch gets pushed to repos.
- Panu -
-
Dominik 'Rathann' Mierzejewski -
Igor Gnatenko -
Kevin Kofler -
Michael Cronenworth -
Michael Schwendt -
Neal Gompa -
Panu Matilainen -
Rafal Luzynski -
Rex Dieter -
Sérgio Basto -
Tomasz Kłoczko