On 04/07/2016 09:12 PM, Phil Sutter wrote:
On Thu, Apr 07, 2016 at 05:35:00PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2016 at 04:35:49PM +0100, James Hogarth wrote:
On 7 Apr 2016 16:07, "Phil Sutter" <psutter@xxxxxxxxxx> wrote:
Hi,
On Thu, Apr 07, 2016 at 12:55:40PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
If you have:
<snip>
Maybe you already thought about this, but I'd add
Recommends: iproute-tc to the main package, and
I guess that's merely a hint, right?
At this time dnf installs recommended packages listed at the same time, but
having it excluded will not fail the install.
Yes. Basically someone who types 'dnf install iproute' in F24+ will
get both packages, but it is still possible to create an image without
the -tc subpackage.
Ah, that's nice. This way users won't have to even know about the
package split.
Requires: iproute-tc = %{version}-%{release} to tc subpackage.
Why should iproute-tc require itself? Could you please explain the
effect this has?
I assume he meant have iproute-tc require the mass matching iproute version
to ensure they are kept in sync when both are installed.
Yep, sorry for the typo.
OK, that explains it. I have been thinking about this dependency already
and suppose it's possible to use tc without the base iproute package.
OTOH I guess nobody really cares. :)
Obsoletes: %{name}%{isa} < the-new-version-release
Hmm. Shouldn't this be '%{?_isa}' instead? At least that's what
https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
recommends. Not sure if that is up to date, though.
In the other part of the thread Panu writes that this doesn't work.
Not sure if this still applies:
| $ repoquery --repoid=psutter-iproute --whatobsoletes iproute
| [...]
| iproute-0:4.5.0-3.fc25.x86_64
| iproute-tc-0:4.5.0-3.fc25.x86_64
| $ dnf list obsoletes
| Last metadata expiration check: 0:00:11 ago on Thu Apr 7 12:03:20 2016.
| Obsoleting Packages
| iproute.x86_64 4.5.0-3.fc25 psutter-iproute
| iproute.x86_64 4.5.0-1.fc25 @psutter-iproute
| iproute-tc.x86_64 4.5.0-2.fc25 rawhide
| iproute.x86_64 4.5.0-1.fc25 @psutter-iproute
| iproute-tc.x86_64 4.5.0-3.fc25 psutter-iproute
| iproute.x86_64 4.5.0-1.fc25 @psutter-iproute
| $ rpm -qp --obsoletes x86_64/iproute-4.5.0-3.fc25.x86_64.rpm
| iproute(x86-64) < 4.5.0-3
| $ rpm -qp --provides x86_64/iproute-4.5.0-1.fc25.x86_64.rpm
| /sbin/ip
| config(iproute) = 4.5.0-1.fc25
| iproute = 4.5.0-1.fc25
| iproute(x86-64) = 4.5.0-1.fc25
| $ rpm -q iproute
| iproute-4.5.0-1.fc25.x86_64
| $ sudo dnf upgrade iproute
| [...]
| Installing:
| iproute-tc x86_64 4.5.0-3.fc25 psutter-iproute 333 k
| replacing iproute.x86_64 4.5.0-1.fc25
| Upgrading:
| iproute x86_64 4.5.0-3.fc25 psutter-iproute 394 k
This all looks sane to me. The spec-file for 4.5.0-3 contains:
| Obsoletes: %{name}%{?_isa} < 4.5.0-3
for both iproute and iproute-tc. Panu?!
If obsoletes are matching provides then there's a bug somewhere in the
dnf stack. I know libsolv has tunables to support that behavior to cover
all the rpm versions in existence so it might be just a wrong flag
someplace.
Rpm itself should behave differently if you try manually upgrading to
those packages (so you'd probably see file conflicts).
- Panu -
Thanks, Phil
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
