Re: pidgin obsoleting itself
2010/6/11 Stu Tomlinson s...@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.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
I think you guys are experiencing the infinite loop bug On Thu, Jun 10, 2010 at 1:52 AM, Michael Schwendt mschwe...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
Getting back to the topic of this original email... On Wed, Jun 9, 2010 at 09:40, Thomas Moschny thomas.mosc...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
pidgin obsoleting itself
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.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@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.mosc...@gmail.com -- Yes, the obsoletes is necessary, if you don't add it, yum will only pull in pidgin-evolution. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Chen Lei supercyp...@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.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@gmail.com: 2010/6/9 Chen Lei supercyp...@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.mosc...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Thomas Moschny thomas.mosc...@gmail.com: 2010/6/9 Chen Lei supercyp...@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.mosc...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Chen Lei supercyp...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Michael Schwendt mschwe...@gmail.com: Competing Obsoletes once again. The packager is playing with fire. Not in this case. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Michael Schwendt mschwe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Michael Schwendt mschwe...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/9 Michael Schwendt mschwe...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On 09/06/10 11:06, Peter Lemenkov wrote: 2010/6/9 Chen Leisupercyp...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On Wed, 9 Jun 2010, Peter Lemenkov wrote: 2010/6/9 Michael Schwendt mschwe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On Wed, Jun 9, 2010 at 11:19, Michael Schwendt mschwe...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
2010/6/10 Michael Schwendt mschwe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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_splitting_packages#.28n:m.29_Many_to_many_replacement It works at the expense of a temporary compat metapackage that needs to be cleaned up later. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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 - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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-development-list/ 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
