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. 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? > > 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: 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? 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? > 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.... > 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).
