12:01 p.m.
Hi,
I am in the process of splitting the 'tc' utility off from iproute
package. The motivation for this comes from two things:
1) Due to it's xt/ipt action, tc depends on iptables.
2) iproute is part of the 'Core' group.
These two in combination lead to iptables being pulled into Core as a
dependency although not strictly necessary - tc is not necessary for
basic system functionality and ip itself works fine without.
So far I added a new 'tc' subpackage to iproute.spec which will contain
tc, all related binaries and configs and relevant man pages. This
package depends on a version of iproute which is greater than the last
release before the split, which should prevent conflicts when updating.
For user convenience though, I would appreciate if an iproute package
update from a pre-split version would automatically pull the tc
subpackage as well. Is this possible without adding a dependency from
'iproute' to 'iproute-tc' (which would defeat the purpose, of course)?
Cheers, Phil
3:47 p.m.
On Tue, Mar 22, 2016 at 06:01:14PM +0100, Phil Sutter wrote:
Hi,
I am in the process of splitting the 'tc' utility off from iproute
package. The motivation for this comes from two things:
1) Due to it's xt/ipt action, tc depends on iptables.
2) iproute is part of the 'Core' group.
These two in combination lead to iptables being pulled into Core as a
dependency although not strictly necessary - tc is not necessary for
basic system functionality and ip itself works fine without.
iptables is also
pulled in by systemd (at least), so this is not enough
to get it out of core.
So far I added a new 'tc' subpackage to iproute.spec which
will contain
tc, all related binaries and configs and relevant man pages. This
package depends on a version of iproute which is greater than the last
release before the split, which should prevent conflicts when updating.
For user convenience though, I would appreciate if an iproute package
update from a pre-split version would automatically pull the tc
subpackage as well. Is this possible without adding a dependency from
'iproute' to 'iproute-tc' (which would defeat the purpose, of course)?
You can use Obsoletes to achieve this. systemd went through a similar
split recently, see
http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?h=f24&id=...
Zbyszek
10:09 a.m.
Hello,
On 03/22/2016 09:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 22, 2016 at 06:01:14PM +0100, Phil Sutter wrote:
> Hi,
>
> I am in the process of splitting the 'tc' utility off from iproute
> package. The motivation for this comes from two things:
>
> 1) Due to it's xt/ipt action, tc depends on iptables.
> 2) iproute is part of the 'Core' group.
>
> These two in combination lead to iptables being pulled into Core as a
> dependency although not strictly necessary - tc is not necessary for
> basic system functionality and ip itself works fine without.
iptables is also pulled in by systemd (at least), so this is not enough
to get it out of core.
The reason for this split is not to get iptables out of
core, but to
have a good way to build new iptables versions with libxtables so bumps.
iproute2 is part of the build environment and depends on libxtables.
With the split only the tc sub package will depend on iptables.
With a libxtables so bump it is either needed to also build iproute2 at
the same time as iptables or to have a (temporary) libxtables provide
for the old so version.
This is also an issue if a customer or user needs to build a newer
iptables version on his system. There is no simple upgrade path for the
most common case.
> So far I added a new 'tc' subpackage to iproute.spec
which will contain
> tc, all related binaries and configs and relevant man pages. This
> package depends on a version of iproute which is greater than the last
> release before the split, which should prevent conflicts when updating.
>
> For user convenience though, I would appreciate if an iproute package
> update from a pre-split version would automatically pull the tc
> subpackage as well. Is this possible without adding a dependency from
> 'iproute' to 'iproute-tc' (which would defeat the purpose, of
course)?
You can use Obsoletes to achieve this. systemd went through a similar
split recently, see
http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?h=f24&id=...
Zbyszek
--
devel mailing list
devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Regards,
Thomas
6:09 a.m.
Hi,
On Tue, Mar 22, 2016 at 06:01:14PM +0100, Phil Sutter wrote:
I am in the process of splitting the 'tc' utility off from
iproute
package. The motivation for this comes from two things:
After considering your feedback (thanks!) and just going for it (thereby
messing up Rawhide a bit), I am kind of stuck in a dilemma regarding
proper implementation of the upgrade path:
The original idea was to have a seamless transition, so users updating
their system would automatically install iproute-tc as it's contents
were previously provided by iproute itself.
Though it seems like in order to implement this, I would have to rename
the original iproute package into e.g. iproute-ip and in addition to
that add a meta package iproute-compat which obsoletes iproute and
requires both iproute-ip and iproute-tc - not the most beautiful
solution in my opinion.
Avoiding the above would break upgrade path as I can't make the "new"
iproute package (which doesn't contain tc) require iproute-tc only if an
update happens from an "old" iproute package.
Ideally we would change dependencies of all packages depending on
iproute to depend on iproute-tc as well if they really need tc itself,
though that takes time of course.
What I can think of now is to simply have iproute require iproute-tc for
a while so updated systems stay functional and after dependencies in
other packages have been sorted drop this requirement from iproute.
What do you think, is this last option acceptable or do I have to go the
"official" way of changing iproute into iproute-ip, iproute-tc and
iproute-compat (thereby forcing all depending packages to adjust as
well)?
Thanks, Phil
7:55 a.m.
On Thu, Apr 07, 2016 at 01:09:11PM +0200, Phil Sutter wrote:
Hi,
On Tue, Mar 22, 2016 at 06:01:14PM +0100, Phil Sutter wrote:
> I am in the process of splitting the 'tc' utility off from iproute
> package. The motivation for this comes from two things:
After considering your feedback (thanks!) and just going for it (thereby
messing up Rawhide a bit), I am kind of stuck in a dilemma regarding
proper implementation of the upgrade path:
The original idea was to have a seamless transition, so users updating
their system would automatically install iproute-tc as it's contents
were previously provided by iproute itself.
Though it seems like in order to implement this, I would have to rename
the original iproute package into e.g. iproute-ip and in addition to
that add a meta package iproute-compat which obsoletes iproute and
requires both iproute-ip and iproute-tc - not the most beautiful
solution in my opinion.
If you have:
(main package)
Obsoletes: %{name} < the-new-version-release
%package tc
Obsoletes: %{name} < the-new-version-release
Both subpackages should get installed on upgrade.
Maybe you already thought about this, but I'd add
Recommends: iproute-tc to the main package, and
Requires: iproute-tc = %{version}-%{release} to tc subpackage.
Zbyszek
8:07 a.m.
On Thu, 2016-04-07 at 12:55 +0000, Zbigniew Jędrzejewski-Szmek wrote:
If you have:
(main package)
Obsoletes: %{name} < the-new-version-release
%package tc
Obsoletes: %{name} < the-new-version-release
Both subpackages should get installed on upgrade.
This is a good trick; I've had to use it recently. I went with this
form:
Obsoletes: %{name}%{isa} < the-new-version-release
This seems better, right?
Michael
8:58 a.m.
On Thu, Apr 07, 2016 at 08:07:01AM -0500, Michael Catanzaro wrote:
On Thu, 2016-04-07 at 12:55 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> If you have:
>
> (main package)
> Obsoletes: %{name} < the-new-version-release
>
> %package tc
> Obsoletes: %{name} < the-new-version-release
>
> Both subpackages should get installed on upgrade.
This is a good trick; I've had to use it recently. I went with this
form:
Obsoletes: %{name}%{isa} < the-new-version-release
Yeah, that's better (matters especially for libraries).
Zbyszek
9:46 a.m.
On 04/07/2016 04:07 PM, Michael Catanzaro wrote:
On Thu, 2016-04-07 at 12:55 +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> If you have:
>
> (main package)
> Obsoletes: %{name} < the-new-version-release
>
> %package tc
> Obsoletes: %{name} < the-new-version-release
>
> Both subpackages should get installed on upgrade.
This is a good trick; I've had to use it recently. I went with this
form:
Obsoletes: %{name}%{isa} < the-new-version-release
This seems better, right?
It might seem better but it doesn't work.
Obsoletes are matched on package names only, and %{name}%{isa} in
packages is in the package provides so the ends never meet and nothing
gets obsoleted.
- Panu -
10:06 a.m.
Hi,
On Thu, Apr 07, 2016 at 12:55:40PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
If you have:
(main package)
Obsoletes: %{name} < the-new-version-release
%package tc
Obsoletes: %{name} < the-new-version-release
Both subpackages should get installed on upgrade.
Oh, this is awesome! Exactly what I have been searching for. No idea why
I didn't try make the new base package obsolete the old one.
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?
Requires: iproute-tc = %{version}-%{release} to tc subpackage.
Why should iproute-tc require itself? Could you please explain the
effect this has?
On Thu, Apr 07, 2016 at 08:07:01AM -0500, Michael Catanzaro wrote:
This is a good trick; I've had to use it recently. I went with
this
form:
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.
Thanks, Phil
10:35 a.m.
On 7 Apr 2016 16:07, "Phil Sutter" <psutter(a)redhat.com> 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.
> 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.
12:35 p.m.
On Thu, Apr 07, 2016 at 04:35:49PM +0100, James Hogarth wrote:
On 7 Apr 2016 16:07, "Phil Sutter"
<psutter(a)redhat.com> 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.
> > 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.
> 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.
Zbyszek
1:12 p.m.
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(a)redhat.com> 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?!
Thanks, Phil
10:43 p.m.
On Thu, 2016-04-07 at 17:46 +0300, Panu Matilainen wrote:
It might seem better but it doesn't work.
Obsoletes are matched on package names only, and %{name}%{isa} in
packages is in the package provides so the ends never meet and
nothing
gets obsoleted.
Thanks for pointing this out... no doubt saved me a lot of frustration.
Michael
12:15 a.m.
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(a)redhat.com> 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
2950
days inactive
2967
days old
13 comments
6 participants
participants (6)
-
James Hogarth -
Michael Catanzaro -
Panu Matilainen -
Phil Sutter -
Thomas Woerner -
Zbigniew Jędrzejewski-Szmek