The problem will never happen anymore if libs + all packages, requiring them, are built before publishing the updated library into the repository.
2014-04-05 22:23 GMT+04:00 Paulo César Pereira de Andrade < [email protected]>: > 2014-04-05 15:15 GMT-03:00 Bernhard Rosenkränzer <[email protected]>: > > Hi, > > > > > > On 2014-04-05 18:02, Paulo César Pereira de Andrade wrote: > >> > >> I cannot work on cooker for 24 hours now, I pinged in irc when > >> detected the problem but nobody commented :-( > > > > > > That can happen at times -- for example, I was out in nowhere with Chwido > > for the day (seems he likes the same remote places I do). > > > > > >> The issue is that ncurses was updated, and it changed major of > >> libncursesw. It did properly follow Mandriva libname specs changing > >> the major of the package, e.g. changed libncursesw5 to libncursesw6, > >> *but* when publishing, "abf" just removed all packages generated > >> by the previous ncurses, that included libncursesw5. > > > > > > That's the right thing to do, it's just wrong to have a binary package > that > > doesn't have a corresponding source package in the tree. > > It does mean, however, that we have to be extra careful -- build the > compat > > package providing the old soname BEFORE building the new package with the > > updated soname. > > Anything that can fail will fail, so this problem will repeat again and > again > if nothing is changed, but most times it does not break the chroot... > > > Maybe abf's publishing tests should be extended to catch this? Right now > it > > warns if a package can't be installed because it conflicts with itself or > > the likes. A check for removing a .so.X that is still needed by something > > else would be great (and an urpmq --whatrequires call shouldn't be too > > expensive). > > I believe my suggestion idea is better described at > https://abf.io/abf/abf-ideas/issues/128#comment4931 > and the garbage collector (continuing 4931) at > https://abf.io/abf/abf-ideas/issues/128#comment4932 > > >> Anyway, to fix the cooker issue, I hereby request some kind of > >> abf access, maybe a way to upload files, e.g. rebuild bash > >> locally with the newer libncursesw (but I would do it only for > >> i586 and x86_64) and upload it, at least this way I would not > >> be blocked from working for at least 24 hours. > > > > > > Certainly not opposed to giving you more access (but I don't have the > > privileges to do so myself) -- but you could have fixed this even without > > more access, simply locate an older ncurses and re-publish it. That would > > have killed libncursesw6, but nothing uses that yet. Would have been good > > enough to get things running again so a compat package could be built > (and > > then ncurses 6 could be published again). > > Well, mdawkins did copy rpms from openmandriva2014.0 to cooker, but > now metadata regeneration does not happen. Apparently another abf issue, > as it is not the first time it says "metadata already queued for > regeneration" > but looks like only regenerates it after someone from abf interfering, i.e. > after like 8+ hours. > > > ttyl > > bero > > Thanks, > Paulo > >
