Le Mardi 22 Juillet 2003 04:48, Andi Payn a �crit : > On Monday 21 July 2003 18:24, Olivier Thauvin wrote: > > Le Mardi 22 Juillet 2003 02:41, Andi Payn a �crit : > > > Are there any examples where a package obsoletes %name but doesn't also > > > provide %name like this? > > > > Yes, I found lot. > > > > You should know all rpm since version 4 provides %name = > > %version-%release without adding a specific provide in spec. > > Yes; that's why I thought it strange that freetds-devel explicitly provides > freetds-devel when it already happens automatically. > > And just to make sure, packages don't automatically obsolete %name < > %version-%release or anything like that; the update logic that essentially > simulates this is completely separate from the obsoletes logic. Right? > > > Then a package obsoleting his %name always obsoletes this provides. > > Right; what I was asking was whether there are any packages that obsolete > %name, other than cases where they also explicitly provide %name (or where > the -devel packages provides %name-devel, etc., as in the freetds case). > > If a package is providing %name, that's already one tag that's there for no > reason (either a mistake, or a packager who doesn't understand the system, > or a leftover from years ago). In that case, the logic behind that > package's tags is suspect.
Yes :) > > But if there are packages that don't provide %name but do obsolete %name, > that's an indication that someone's possibly thought it through correctly > and did this for a reason. > > Am I making myself clear, or just more confusing? Useally you provides and obsoletes the old package (rpmlint warn if not). But someetimes, for somes reason, you must only obsoletes the old packages. I haven't example at time (maybe %libname%major), but I allready found this case. > > > > In other words, I think that if package foo provides bar, and you > > > install foo, rpm-4.2 removes bar even if foo doesn't also obsolete bar. > > > > No, this was a bug, fix since -7mdk (don't remember exactly, but by > > fpons), and fixed by RH after RH9.0 released: > > Ah, that's what I get for reading RH9 docs.... (And don't the Redhat > thought police come after you if you call it 9.0, yelling "there is no > dot!" and beating you with rubber hoses until you confess that "the latest > linux" doesn't mean "2.6.0-test1"?) > > > foo provides bar; rpm -Uvh foo you have foo and bar > > foo obsoletes bar; rpm -Uvh foo, you have only foo, bar was removed > > foo provides and obsoletes bar; you have only foo, bar was removed, but > > you can keep packages requiring bar. > > This makes sense: there are three different behaviors you might want, and > this provides a way to get any of them. > > But I still don't get why a package would provide %name, and the case for > obsoleting %name seems pretty uncommon. Let's say that bar provides foo > (otherwise, there's no issue at all), and we're now going to rpm -Uvh foo: Hard to follow :) Why providing foo and ovsolete foo: I have a (bad but recent) example in plf (just for the example): lmule was allways call lmule, other packages requires lmule. The name recently change for xmule. If I want install lmule, i type: urpmi lmule because xmule provide lmule, urpmi can find it and install it without any problem. The other things, this does not break all depandencies and give time to fix without breaking the whole distro. > > foo neither provides nor obsoletes %name; you have foo and bar. > foo provides %name; exactly the same (because foo automatically provides > %name whether you specify it or not). > foo obsoletes %name; you have only foo, you can keep packages requiring foo > (because foo automatically provides foo), but not packages requiring bar. > foo provides and obsoletes %name; exactly the same. > > Right? hum which %name ? > > So, providing %name never has any effect. Obsoleting %name has an effect if > there's another package that provides foo, that the real foo is > incompatible with. But, if you've found this "lots," does this mean there > are lots of packages where this issue comes up? Somes, yes. > > > wahou ! I hope you still follow me :) > > So do I.... > > > But it's interesting to make a little test, I take basystem (easy to > > build), and make it wrong: > > I usually just build dummy packages, so I can test them on every system I > have (different versions of rpm and all that) with little chance of > breaking anything important.... me too, for testing distlint, because packages a too perfect to test it :)) > > > Next time, I explain with epoch tag... :) > > Yes, and while you're at it, tell us how to use a --with flag to rpmbuild > to select between obsoleting by version or by epoch (but only if you're > building on a weekday, of course). Hum tomorrow -- Linux pour Mac !? Enfin le moyen de transformer une pomme en v�ritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
