> On Jun 6, 2016, at 11:04 PM, Tomasz Pala <go...@polanet.pl> wrote: > > On Mon, Jun 06, 2016 at 17:00:23 -0400, Jeffrey Johnson wrote: > >>> downgrading from repackage lost config files, >>> i.e saved them as .rpmsave leaving original path missing > [...] >> What exactly are you expecting? > > If previous (modified) configs were moved to .rpmsave, anyone should > expect package-provided files to be put in place. >
That depends on the ordering of remove vs install. RPM (and most of its algorithms) depends on install-before-erase. The mere fact that files were renamed to *.rpmsave indicates that remove-before-install was occurring. >> I see rpm renaming modified %config files to *.rpmsave exactly as always, >> nothing more. > > But doesn't install files that were to replace them. > Really? There is nothing in the e-mail report that indicates that files were not installed. There is an indication that the original (and modified) contents were renamed and had to be manually moved back into place. Again, I do not know what is “expected” … what is being reported is what I expect to see (and there is no “loses” in renaming to *.rpmsave). (aside) Yes having to deal with %config renaming is quite tedious. I personally believe that all of %config is fabulously broken and useless. Meanwhile, my obligation is to ensure that the current mechanism “works” in rpm exactly as it is supposed to work, not otherwise. >> FWIW: there is no ???downgrade in rpm, and flipping various bits in polled >> to disable version comparisons >> and file conflicts in order to achieve ???downgrade??? has almost nothing to >> do with %config handling. > > I guess this is related to using repackaged.rpm. These types of packages > are known to have manifest different than real contents, so while installing > one might expect such behavior. > I’m not sure how repackaged rpm’s are involved: that isn’t entirely clear from the report. Yes, the header’s in repackaged *.rpm’s have additional tags (of a doubly linked package upgrade chain) appended. And repackaged *.rpm’s are *entirely* best effort. Content may be missing and/or modified: whatever is on the file system when the repackaging occurs is what is loaded into the repackaged rpm. There is nothing in the report that indicates the necessary disablers were used: you can *NOT* just reinstall a repackaged package without additional flags. Presumably those additional flags are buried in the —downgrade alias added by PLD. I have little experience (and certainly no test cases) with how rpm behaves with PLD modifications. Better could and should be done in rpm. But it takes more than repeated complaints of “losing” or “destroying” %config files from heavily modified versions of rpm to achieve development. Meanwhile RPM is doing exactly what I expect, knowing what is implemented. 73 de Jeff _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
