3:40 a.m.
Hi,
pidgin-2.7.1-2.fc13 obsoletes pidgin <= 2.7.1-1.fc13, is that meaningful?
At least it causes package-manager to display an irritating (and
somehow bogus) warning box that it's going to remove pidgin, and needs
confirmation for that.
--
Thomas Moschny <thomas.moschny(a)gmail.com>
3:47 a.m.
2010/6/9 Thomas Moschny <thomas.moschny(a)gmail.com>:
Hi,
pidgin-2.7.1-2.fc13 obsoletes pidgin <= 2.7.1-1.fc13, is that meaningful?
At least it causes package-manager to display an irritating (and
somehow bogus) warning box that it's going to remove pidgin, and needs
confirmation for that.
--
Thomas Moschny <thomas.moschny(a)gmail.com>
--
Yes, the obsoletes is necessary, if you don't add it, yum will only
pull in pidgin-evolution.
Chen Lei
4:15 a.m.
2010/6/9 Thomas Moschny <thomas.moschny(a)gmail.com>:
2010/6/9 Chen Lei <supercyper1(a)gmail.com>:
> Yes, the obsoletes is necessary, if you don't add it, yum will only
> pull in pidgin-evolution.
For which operation? Can you elaborate a bit?
--
Thomas Moschny <thomas.moschny(a)gmail.com>
--
"yum upgrade" from 2.7.1-1 will only pull in new pidgin-evolution
subpackage and del old pidgin if you don't add obsoletes.
Chen Lei
4:20 a.m.
2010/6/9 Thomas Moschny <thomas.moschny(a)gmail.com>:
2010/6/9 Chen Lei <supercyper1(a)gmail.com>:
> Yes, the obsoletes is necessary, if you don't add it, yum will only
> pull in pidgin-evolution.
For which operation? Can you elaborate a bit?
--
Thomas Moschny <thomas.moschny(a)gmail.com>
--
But in this case, the obsoletes seems excessive, since
pidgin-evolution already depends on pidgin. If pidgin-evolution don't
depend on pidgin, the obsoletes is a must, without it pidgin will be
replaced by pidgin-evolution.
Chen Lei
5 a.m.
On Wed, 9 Jun 2010 17:15:01 +0800, Chen wrote:
> 2010/6/9 Chen Lei:
>> Yes, the obsoletes is necessary, if you don't add it, yum will only
>> pull in pidgin-evolution.
>
> For which operation? Can you elaborate a bit?
>
"yum upgrade" from 2.7.1-1 will only pull in new
pidgin-evolution
subpackage and del old pidgin if you don't add obsoletes.
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1996754
Competing "Obsoletes" once again. The packager is playing with fire.
5:06 a.m.
2010/6/9 Chen Lei <supercyper1(a)gmail.com>:
But in this case, the obsoletes seems excessive, since
pidgin-evolution already depends on pidgin. If pidgin-evolution don't
depend on pidgin, the obsoletes is a must, without it pidgin will be
replaced by pidgin-evolution.
If it pidgin-evolution was previously in main package, then this
obsoletes is required. W/o this requires users may suffer from missing
functionality after upgrade.
Briefly:
* We need to split off p.-e, from pidgin
* We need to install both of them while upgrading (Obsoletes in
pidgin-evo) in order not to loose functionality.
* We need to not erase main pidgin (Obsoletes in pidgin)
--
With best regards, Peter Lemenkov.
5:07 a.m.
2010/6/9 Michael Schwendt <mschwendt(a)gmail.com>:
On Wed, 9 Jun 2010 17:15:01 +0800, Chen wrote:
> > 2010/6/9 Chen Lei:
> >> Yes, the obsoletes is necessary, if you don't add it, yum will only
> >> pull in pidgin-evolution.
> >
> > For which operation? Can you elaborate a bit?
> >
> "yum upgrade" from 2.7.1-1 will only pull in new pidgin-evolution
> subpackage and del old pidgin if you don't add obsoletes.
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1996754
Competing "Obsoletes" once again. The packager is playing with fire.
--
I test yum several days ago, if we split foo package into into foo and
bar, we must add obsoletes to both subpackages.
When we type "yum upgrade", old foo will be replaced by new foo and bar.
Chen Lei
5:18 a.m.
2010/6/9 Michael Schwendt <mschwendt(a)gmail.com>:
On Wed, 9 Jun 2010 14:07:09 +0400, Peter wrote:
> > Competing "Obsoletes" once again. The packager is playing with fire.
>
> Not in this case.
Both pidgin-evolution and pidgin obsolete pidgin <= 2.7.1-1.fc13
Fun for the package resolver.
Then file a bug against yum if this is a difficulty for him.
--
With best regards, Peter Lemenkov.
5:19 a.m.
2010/6/9 Michael Schwendt <mschwendt(a)gmail.com>:
On Wed, 9 Jun 2010 14:07:09 +0400, Peter wrote:
> > Competing "Obsoletes" once again. The packager is playing with fire.
>
> Not in this case.
Both pidgin-evolution and pidgin obsolete pidgin <= 2.7.1-1.fc13
Fun for the package resolver.
Ah, yes - version should be lowered in this case. Please,
disregard my previous message.
--
With best regards, Peter Lemenkov.
5:19 a.m.
On Wed, 9 Jun 2010 14:06:48 +0400, Peter wrote:
2010/6/9 Chen Lei:
> But in this case, the obsoletes seems excessive, since
> pidgin-evolution already depends on pidgin. If pidgin-evolution don't
> depend on pidgin, the obsoletes is a must, without it pidgin will be
> replaced by pidgin-evolution.
If it pidgin-evolution was previously in main package, then this
obsoletes is required. W/o this requires users may suffer from missing
functionality after upgrade.
Briefly:
* We need to split off p.-e, from pidgin
* We need to install both of them while upgrading (Obsoletes in
pidgin-evo) in order not to loose functionality.
* We need to not erase main pidgin (Obsoletes in pidgin)
I wonder who's spreading theories like that? It's not the first time
this has come up in the past weeks. Most recently affected was nagios.
You _cannot_ add _optional_ packages to a user's installation _without_
proper dependencies somewhere else. Attempts at trying to do that with
Obsoletes are invasive and prone to getting it completely wrong.
5:23 a.m.
On 09/06/10 11:06, Peter Lemenkov wrote:
2010/6/9 Chen Lei<supercyper1(a)gmail.com>:
> But in this case, the obsoletes seems excessive, since
> pidgin-evolution already depends on pidgin. If pidgin-evolution don't
> depend on pidgin, the obsoletes is a must, without it pidgin will be
> replaced by pidgin-evolution.
If it pidgin-evolution was previously in main package, then this
obsoletes is required. W/o this requires users may suffer from missing
functionality after upgrade.
Briefly:
* We need to split off p.-e, from pidgin
Fine.
* We need to install both of them while upgrading (Obsoletes in
pidgin-evo) in order not to loose functionality.
The Obsoletes: in pidgin-evo causes pidgin-evo to be pulled in, which is
fine. The package should obsolete pidgin packages prior to the split but
not the ones after the split.
* We need to not erase main pidgin (Obsoletes in pidgin)
Not needed if pidgin-evo depends on pidgin itself - the regular
dependency mechanism should pull the main pidgin package in. And since
the new pidgin package is versioned later than the split, it's no longer
obsoleted by the pidgin-evo subpackage. Does that not work?
Paul.
5:38 a.m.
On Wed, 9 Jun 2010, Peter Lemenkov wrote:
2010/6/9 Michael Schwendt <mschwendt(a)gmail.com>:
> Competing "Obsoletes" once again. The packager is playing with fire.
Not in this case.
It seems to me that this is using something that happens to work for yum
(and maybe not for other utilities, different yum versions, etc. ) rather
than a defined feature to handle this situation. So I agree that the
packager is playing with fire and there are probably better ways of
achieving this result.
Michael Young
5:49 a.m.
On Wed, 09 Jun 2010 11:23:49 +0100, Paul wrote:
The Obsoletes: in pidgin-evo causes pidgin-evo to be pulled in, which
is
fine. The package should obsolete pidgin packages prior to the split but
not the ones after the split.
Sounds [more] correct.
> * We need to not erase main pidgin (Obsoletes in pidgin)
Not needed if pidgin-evo depends on pidgin itself - the regular
dependency mechanism should pull the main pidgin package in. And since
the new pidgin package is versioned later than the split, it's no longer
obsoleted by the pidgin-evo subpackage. Does that not work?
That is closer to ordinary package renaming,
A renamed to B : B obsoletes A + B provides A
with the exception that B does not provide A, but requires a specific
version of A.
A => pidgin
B => pidgin-evolution
9:38 a.m.
On Wed, Jun 9, 2010 at 11:19, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Wed, 9 Jun 2010 14:06:48 +0400, Peter wrote:
> 2010/6/9 Chen Lei:
>
> > But in this case, the obsoletes seems excessive, since
> > pidgin-evolution already depends on pidgin. If pidgin-evolution don't
> > depend on pidgin, the obsoletes is a must, without it pidgin will be
> > replaced by pidgin-evolution.
>
> If it pidgin-evolution was previously in main package, then this
> obsoletes is required. W/o this requires users may suffer from missing
> functionality after upgrade.
>
> Briefly:
>
> * We need to split off p.-e, from pidgin
> * We need to install both of them while upgrading (Obsoletes in
> pidgin-evo) in order not to loose functionality.
> * We need to not erase main pidgin (Obsoletes in pidgin)
I wonder who's spreading theories like that? It's not the first time
this has come up in the past weeks. Most recently affected was nagios.
I implemented it based on recommendations on the yum wiki that I saw
someone else referred to in #fedora-devel :
http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit
You _cannot_ add _optional_ packages to a user's installation
_without_
proper dependencies somewhere else. Attempts at trying to do that with
Obsoletes are invasive and prone to getting it completely wrong.
I thought that a reference from yum was a reasonably safe bet to be a
good thing to follow.
Regards,
Stu.
11:08 a.m.
On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote:
I implemented it based on recommendations on the yum wiki that I saw
someone else referred to in #fedora-devel :
http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit
Well, that's exactly an example where the two Obsoletes compete with
eachother. It works only partially. For an ordinary Yum update.
It fails for a Yum install. I warn about such competing Obsoletes, because
they strictly require the user to go the "yum -y update ; yum install ..."
route everytime they want to install an additional package. When talking
to some packagers related to broken deps, I've learned that some have
tried to add extra Obsoletes to make "yum install ..." pull latest updates
for new sub-packages just as "yum update ..." does. That has lead to bad
updates.
In case of pidgin-evolution, it only works because pidgin-evolution
also _requires_ (!) a specific release of pidgin. If that weren't the case,
a "yum install pidgin-evolution" would simply remove (= obsolete!) pidgin.
For a Yum install, an arbitrary package's Obsoletes are not considered
unless the package becomes part of the transaction set.
Competing Obsoletes => playing with fire.
> You _cannot_ add _optional_ packages to a user's
installation _without_
> proper dependencies somewhere else. Attempts at trying to do that with
> Obsoletes are invasive and prone to getting it completely wrong.
I thought that a reference from yum was a reasonably safe bet to be a
good thing to follow.
It fails as outlined above.
11:36 a.m.
2010/6/10 Michael Schwendt <mschwendt(a)gmail.com>:
On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote:
> I implemented it based on recommendations on the yum wiki that I saw
> someone else referred to in #fedora-devel :
> http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit
Well, that's exactly an example where the two Obsoletes compete with
eachother. It works only partially. For an ordinary Yum update.
It fails for a Yum install. I warn about such competing Obsoletes, because
they strictly require the user to go the "yum -y update ; yum install ..."
route everytime they want to install an additional package. When talking
to some packagers related to broken deps, I've learned that some have
tried to add extra Obsoletes to make "yum install ..." pull latest updates
for new sub-packages just as "yum update ..." does. That has lead to bad
updates.
In case of pidgin-evolution, it only works because pidgin-evolution
also _requires_ (!) a specific release of pidgin. If that weren't the case,
a "yum install pidgin-evolution" would simply remove (= obsolete!) pidgin.
For a Yum install, an arbitrary package's Obsoletes are not considered
unless the package becomes part of the transaction set.
Competing Obsoletes => playing with fire.
I think it's accept in rawhide since it can provide a sane upgrade
path for dist upgrade.
Chen Lei
12:10 p.m.
On Wed, 2010-06-09 at 18:08 +0200, Michael Schwendt wrote:
On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote:
> I implemented it based on recommendations on the yum wiki that I saw
> someone else referred to in #fedora-devel :
> http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit
Well, that's exactly an example where the two Obsoletes compete with
eachother. It works only partially. For an ordinary Yum update.
It fails for a Yum install.
I'm not sure what you mean by "fail" here. The above is the only way to
do a "package split" ... which is to say you have:
1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah
2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a
single file.
3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2
(because that's what they had before).
...if at the end of the "split" you want "yum install pkgA" to
install
pkgA-blah (or vice versa), then it's not _just_ a split and you probably
want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the
first versions). You can do this instead of the obsoletes, but I don't
see the point.
12:15 p.m.
Le mercredi 09 juin 2010 à 12:19 +0200, Michael Schwendt a écrit :
You _cannot_ add _optional_ packages to a user's installation
_without_
proper dependencies somewhere else. Attempts at trying to do that with
Obsoletes are invasive and prone to getting it completely wrong.
Fonts SIG side we've managed several packaging splits with this recipe
http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitti...
It works at the expense of a temporary compat metapackage that needs to
be cleaned up later.
--
Nicolas Mailhot
12:23 p.m.
On Wed, 09 Jun 2010 13:10:10 -0400, James wrote:
> On Wed, 9 Jun 2010 15:38:48 +0100, Stu wrote:
>
> > I implemented it based on recommendations on the yum wiki that I saw
> > someone else referred to in #fedora-devel :
> > http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit
>
> Well, that's exactly an example where the two Obsoletes compete with
> eachother. It works only partially. For an ordinary Yum update.
> It fails for a Yum install.
I'm not sure what you mean by "fail" here.
"fail" as in "it doesn't split an installed package into two, but it
replaces
an installed package with another one".
The above is the only way to
do a "package split" ...
No. More correct is the Fedora Packaging Guidelines version, which adds
a Requires on the base package to the new [sub-]package. But see below.
which is to say you have:
1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah
2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a
single file.
3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2
(because that's what they had before).
...if at the end of the "split" you want "yum install pkgA" to
install
pkgA-blah (or vice versa), then it's not _just_ a split and you probably
want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the
first versions). You can do this instead of the obsoletes, but I don't
see the point.
If at the end of the split user does "yum install pkgA-blah-2", this
erases pkgA-1 ... unless pkgA-blah-2 strictly requires pkgA-2, which
is not always desired.
1:39 p.m.
On Wed, 2010-06-09 at 19:23 +0200, Michael Schwendt wrote:
On Wed, 09 Jun 2010 13:10:10 -0400, James wrote:
> which is to say you have:
>
> 1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah
>
> 2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a
> single file.
>
> 3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2
> (because that's what they had before).
>
> ...if at the end of the "split" you want "yum install pkgA" to
install
> pkgA-blah (or vice versa), then it's not _just_ a split and you probably
> want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the
> first versions). You can do this instead of the obsoletes, but I don't
> see the point.
If at the end of the split user does "yum install pkgA-blah-2", this
erases pkgA-1 ... unless pkgA-blah-2 strictly requires pkgA-2, which
is not always desired.
And if the user never has pkgA-1 installed, and does "install
pkgA-blah" then that's all they'll get. To put it another way when the
user first installed pkgA-1 they could have wanted:
1. What pkgA-2 and pkgA-blah-2 provide.
2. What pkgA-2 provides.
3. What pkgA-blah-2 provides.
...but they got #1 because that was all pkgA-1 provided. Now there is a
package split and the user can choose any of #1, #2 or #3.
If you only want them to be able to choose between #1 and #2 (or #1 and
#3) then you need some kind of requires _as well_. But that's because
you have some requirement _as well_ as just a package split.
--
James Antill - james(a)fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory
2:38 p.m.
On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:
On Wed, 2010-06-09 at 19:23 +0200, Michael Schwendt wrote:
> On Wed, 09 Jun 2010 13:10:10 -0400, James wrote:
> > which is to say you have:
> >
> > 1. pkgA-1 contains two files: /usr/bin/A and /usr/bin/A-blah
> >
> > 2. You now want to have pkgA-2 and pkgA-blah-2, which each contain a
> > single file.
> >
> > 3. You want anyone who had pkgA-1 to have both pkgA-2 and pkgA-blah-2
> > (because that's what they had before).
> >
> > ...if at the end of the "split" you want "yum install pkgA"
to install
> > pkgA-blah (or vice versa), then it's not _just_ a split and you probably
> > want to use a Requires (as you would if pkgA-2/pkgA-blah-2 were the
> > first versions). You can do this instead of the obsoletes, but I don't
> > see the point.
>
> If at the end of the split user does "yum install pkgA-blah-2", this
> erases pkgA-1 ... unless pkgA-blah-2 strictly requires pkgA-2, which
> is not always desired.
And if the user never has pkgA-1 installed, and does "install
pkgA-blah" then that's all they'll get.
If you modify the scenario, we will talk past eachother.
The scenario is:
1. User has pkgA-1 installed.
2. Packager performs a split and introduces at least one new subpkg, so:
pkgA-blah-2 and pkgA-2.
3. User follows some documentation and runs "yum install pkgA-blah" to
add something.
4. Package "pkgA" is erased (obsoleted) => bug.
To put it another way when the
user first installed pkgA-1 they could have wanted:
Nothing else than "pkgA-1", because user cannot foresee the split
of either the package contents OR the package dependencies. Or user
simply relied on the distribution's installer to install packages.
1. What pkgA-2 and pkgA-blah-2 provide.
2. What pkgA-2 provides.
3. What pkgA-blah-2 provides.
...but they got #1 because that was all pkgA-1 provided. Now there is a
package split and the user can choose any of #1, #2 or #3.
If you only want them to be able to choose between #1 and #2 (or #1 and
#3) then you need some kind of requires _as well_. But that's because
you have some requirement _as well_ as just a package split.
That isn't what I refer to. For some splits you don't have a requirement.
See e.g. a real-world example, where installing/adding a Nagios plugin
package removed Nagios because of competing Obsoletes:
https://bugzilla.redhat.com/590709#c13
All is well (including the self-Obsoletes) if sub-packages OR separate
add-on packages, which obsolete a package, also depend on that same package.
Where that isn't true, competing Obsoletes => playing with fire.
As explained.
5 p.m.
On Wed, 2010-06-09 at 21:38 +0200, Michael Schwendt wrote:
On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:
> And if the user never has pkgA-1 installed, and does "install
> pkgA-blah" then that's all they'll get.
If you modify the scenario, we will talk past eachother.
The scenario is:
I didn't.
1. User has pkgA-1 installed.
2. Packager performs a split and introduces at least one new subpkg, so:
pkgA-blah-2 and pkgA-2.
3. User follows some documentation and runs "yum install pkgA-blah" to
add something.
4. Package "pkgA" is erased (obsoleted) => bug.
Ok, so, as I said before...
1. User has nothing installed.
2. User follows some documentation and runs "yum install pkgA-blah" to
add something.
3. Package "pkgA" is not installed.
...the split makes no difference, either pkgA-blah implies pkgA or it
does not. If it does not and the user asks for just pkgA-blah, then we
don't give them pkgA.
Now you might argue that there are packages, for _both_ our examples,
where the user really does want pkgA as well (and it's not a strict
requirement).
We may get suggests eventually, but this has nothing to do with
Obsoletes.
That isn't what I refer to. For some splits you don't have a
requirement.
See e.g. a real-world example, where installing/adding a Nagios plugin
package removed Nagios because of competing Obsoletes:
https://bugzilla.redhat.com/590709#c13
This example is a little more convoluted, esp. as F-12 doesn't have
-common before and -common always had it (and should thus. have used a
"Conflicts: nagios < 3.2.1-2" in nagios-common).
But here I think you have:
nagios-1
nagios-2 = Obsoletes: nagios < 2
nagios-common-2 = Obsoletes: nagios < 2
nagios-plugin-load = Requires: nagios-plugins = 1
nagios-plugins = Requires: nagios-common
...and then if the user does "yum install nagios-plugin-load" before
they've updated nagios-common then yum will install just nagios-common
(I think).
But, again, you are _assuming_ that the user always installed nagios
for what became both nagios and nagios-common. This is not necessarily
true.
10:07 p.m.
Michael Schwendt wrote:
It fails for a Yum install. I warn about such competing Obsoletes,
because
they strictly require the user to go the "yum -y update ; yum install ..."
route everytime they want to install an additional package.
Installing stuff on a non-updated system is playing with fire. It should be
common sense to update your system before doing any other package operation.
Kevin Kofler
12:52 a.m.
On Wed, 09 Jun 2010 18:00:15 -0400, James wrote:
On Wed, 2010-06-09 at 21:38 +0200, Michael Schwendt wrote:
> On Wed, 09 Jun 2010 14:39:52 -0400, James wrote:
> > And if the user never has pkgA-1 installed, and does "install
> > pkgA-blah" then that's all they'll get.
>
> If you modify the scenario, we will talk past eachother.
> The scenario is:
I didn't.
http://poelcat.wordpress.com/2010/04/28/monty-python-does-the-fedora-deve...
> 1. User has pkgA-1 installed.
Ok, so, as I said before...
1. User has nothing installed.
We can stop here already. Let's meet somewhere in the middle. Your case is
_another_ valid scenario, but it disregards the simple fact that the
package split leads to an install operation erasing an already installed
package and thus crippling/damaging the installation depending on what
gets removed. As it _may be_ possible in some cases to fix the package
dependencies and avoid such a scenario, I just say that playing with
Obsoletes bears risks.
Now you might argue that there are packages, for _both_ our
examples,
where the user really does want pkgA as well (and it's not a strict
requirement).
We may get suggests eventually, but this has nothing to do with
Obsoletes.
In general, only the "Obsoletes" lead to erasing an installed package,
which is the dangerous part about introducing too many Obsoletes in
packages or sub-packages. [We've escaped from the times when Provides
also replaced packages.]
> That isn't what I refer to. For some splits you don't
have a requirement.
> See e.g. a real-world example, where installing/adding a Nagios plugin
> package removed Nagios because of competing Obsoletes:
> https://bugzilla.redhat.com/590709#c13
This example is a little more convoluted, esp. as F-12 doesn't have
-common before and -common always had it (and should thus. have used a
"Conflicts: nagios < 3.2.1-2" in nagios-common).
That ticket is just one example of "Obsoletes" having lead to packaging
bugs. First, a package split lead to erasing an installed package during a
normal _update_ scenario. Then followed attempts at fixing up the
packages with competing Obsoletes for a specific _install_ scenario,
which also didn't work out, because of missing strict dependencies due to
how the split is done.
12:52 a.m.
On Thu, 10 Jun 2010 05:07:16 +0200, Kevin wrote:
> It fails for a Yum install. I warn about such competing
Obsoletes, because
> they strictly require the user to go the "yum -y update ; yum install
..."
> route everytime they want to install an additional package.
Installing stuff on a non-updated system is playing with fire.
The fire is added by "Obsoletes", though.
It should be
common sense to update your system before doing any other package operation.
Which is also my recommendation.
4:46 p.m.
I think you guys are experiencing the infinite loop bug....
On Thu, Jun 10, 2010 at 1:52 AM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Thu, 10 Jun 2010 05:07:16 +0200, Kevin wrote:
> > It fails for a Yum install. I warn about such competing Obsoletes, because
> > they strictly require the user to go the "yum -y update ; yum install
..."
> > route everytime they want to install an additional package.
>
> Installing stuff on a non-updated system is playing with fire.
The fire is added by "Obsoletes", though.
> It should be
> common sense to update your system before doing any other package operation.
Which is also my recommendation.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
7:46 p.m.
Getting back to the topic of this original email...
On Wed, Jun 9, 2010 at 09:40, Thomas Moschny <thomas.moschny(a)gmail.com> wrote:
pidgin-2.7.1-2.fc13 obsoletes pidgin <= 2.7.1-1.fc13, is that
meaningful?
Yes, it's meaningful because it allows updates to pidgin > 2.7.1-1 to
pull in the pidgin-evolution package without requiring an explicit
dependency on pidgin-evolution (which was the whole point of splitting
out the sub-package in the first place, see bug #581144)
At least it causes package-manager to display an irritating (and
somehow bogus) warning box that it's going to remove pidgin, and needs
confirmation for that.
I'm not sure which "package-manager" this is, but I suggest the fix is
to make "package-manager" not display this warning if it is not really
removing pidgin.
Regards,
Stu.
3:15 a.m.
2010/6/11 Stu Tomlinson <stu(a)nosnilmot.com>:
> At least it causes package-manager to display an irritating (and
> somehow bogus) warning box that it's going to remove pidgin, and needs
> confirmation for that.
I'm not sure which "package-manager" this is, but I suggest the fix is
to make "package-manager" not display this warning if it is not really
removing pidgin.
Meant to write "PackageKit". And this is surely a PackageKit bug.
Today this happened again, for the awn-extras-applets package, which
also self-obsoletes: % rpm -q --obsoletes awn-extras-applets
awn-extras-applets-devel < 0.4.0-14.fc13
awn-extras-applets < 0.4.0-14.fc13
for whatever reason).
--
Thomas Moschny <thomas.moschny(a)gmail.com>
4:18 a.m.
On Fri, 11 Jun 2010 10:15:55 +0200, Thomas wrote:
Meant to write "PackageKit". And this is surely a
PackageKit bug.
Today this happened again, for the awn-extras-applets package, which
also self-obsoletes: % rpm -q --obsoletes awn-extras-applets
awn-extras-applets-devel < 0.4.0-14.fc13
awn-extras-applets < 0.4.0-14.fc13
for whatever reason).
Non-arch specific self-Obsoletes like that are increasingly common as a
way to prevent multiarch repo dependency problems.
5069
days inactive
5071
days old
31 comments
11 participants
participants (11)
-
Brandon Lozza -
Chen Lei -
James Antill -
Kevin Kofler -
M A Young -
Michael Schwendt -
Nicolas Mailhot -
Paul Howarth -
Peter Lemenkov -
Stu Tomlinson -
Thomas Moschny