> On Jun 7, 2016, at 10:57 PM, Tomasz Pala <[email protected]> wrote: > > On Tue, Jun 07, 2016 at 14:29:24 -0400, Jeffrey Johnson wrote: > >>>> There are also better solutions than /var/spool/repackage that can be >>>> attempted these >>>> days. >>> >>> What are they? Filesystem-level snapshots are not suitable when you need >>> to revert anything older than a few hours maybe (can anyone afford >>> restoring 2 weeks old state and replaying every other change that was >>> made meanwhile?), so what else? >>> >>> And if not for --rollback, repackages are great for cherry-picking >>> single package do downgrade. > > http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html >
OK, I’ll bite: you quote James Antill from 8 years ago … what are you trying to say? Please … > FS-level snapshots are shortest way to 'reboot to upgrade' insanity. > So you seem to not like “FS snapshots” … Good, I think FS snapshots have little to do with —rollback too, we may possibly agree. FS snapshots have a usage case, but not with —rollback for package management. >> <pld-devel@ ???> is not the place for RPM development discussions. > > It's you who are doing some obsolescence suggestions, just don't do that > if you have nothing clear as a replacement or going to make it secret. > Obsolesence? Hardly … there are some serious flaws in RPM in need of repair 20+ years later … including %config handling, the start of this thread. (aside) I do have some serious credentials having 18+ years experience with RPM, and also having implemented 2-3 —rollback schemes in RPM, mostly useless for other reasons. You could (but apparently the EU funded Mancoosi task force 3 on transactional package management mail archives are no longer available, oh well) read the history of what has transpired this century, certainly more details since James Antill posted in 2008, if really interested … … but go ahead and claim vaporware or accuse me of keeping my ideas “secret” (or worse, not able to backup my claims with an implementation) if you insist. All I meant to suggest is that the PLD devel list is _NOT_ the pace to discuss RPM package management issues (including repackaging, and —rollback) seriously. >> This thread is/was diagnosing a problem and devising a solution, not >> otherwise. > > Different approach to entire repackage (that YOU suggested) is also a > solution. > What are you trying to say here? Do you like/want repackaging or not? I did successfully implement repackaging (what is currently used by PLD) while @redhat in like 2003 or so. I’m happy you like what I implemented, but damfino what you wish changed. > The only alternative I know: > https://www.redhat.com/archives/rhelv6-beta-list/2010-June/msg00056.html > yum-history, is not suitable for PLD due to rolling releases - package I > had might be not available for download anymore. yum-plugin-fs-snapshot > is a no-go on any non-desktop or non-singleuser machine. That leaves us > with not a single 'better solutions these days’. Um, a yum-history citation, and from 2010— which depends on what is called a “yumdb” — is mostly useless, perhaps more useless than FS snapshots that you seem to dislike. JMHO, YMMV. We can explore details as you wish ... The very serious flaw(s) with a yumdb are: 1) any value (like a nominal ~128b string containing package NEVRA) uses an entire (usually 4Kb) block on a FS. That is 4096 - 128 = 3968b of wasted disk space. 2) there is no means to truncate yumdb file system usage, a yumdb is forever (well, you can just nuke the entire FS tree whenever you want to regain FS space for other uses) I can/will enumerate several additional flaws if absolutely necessary. We seem to agree that yum-history is not appropriate for PLD (and more generally, rather a waste of disk space). > I remember you wrote about libgit a few years ago, but that might handle > %config problems only, but not restoring packages to some previous > (working) state. > You’ll have to remind me of what I wrote, I have written lots about RPM over the years … >> See Poky/Yocto image construction for what RPM5 can already do when >> used intelligently. > > I doubt embedded platform uses rpm5 to solve issues like "there is a > problem with foo using libbar we have upgraded last week, need to > restore previous versions and do some more tests on separate/clean > environment". So unless you are willing to share the mysterious features > that might be used instead repackages, I'm not going to waste my time > digging in system build with different principles in mind and for entirely > different purpose than PLD. That's great, if rpm5 solves their problems > - can it solve ours? If so, just tell us how. No need for elaborates. > You need to study before responding: Poky/Yocto install images are produced by cross-compilation on standard *x86 blade hardware, nothing whatsoever to do with “embedded”, and (perhaps) very little to do with “repackaging”. I mentioned P/Y largely because of what is called a “solvedb”, which is little more than an rpmdb with a URL pointer to the original (or copy) *.rpm package, which solves the problem of removed/erased files that repackaging will never be able to solve correctly. Meanwhile, <[email protected]>, not <[email protected]>, is the proper forum for discussion of RPM. That is all that I said. > OK, I know one solution: fetching rpms via permanent-store proxy like > wwwoffle and keeping those rpms forever, as there is no way to implement > "keep THAT time since package was upgraded" policy. Repackages are > superior in two ways: > 1. they are timestamped on upgrade, so one could remove old ones, > 2. they retain current configuration within. > Once you remove “old ones” (presumably ones == packages), you risk a loss of referential integrity. We might (but unclear) even agree on this point. I know of at least 3 linux distros (including @redhat.com) that have independently discovered that you MUST keep a permanent record of all published packages in order to do “upgrades” … or possibly “downgrades” … reliably. (aside) Please don’t take my comments personally: I’ll be happy to discuss better RPM implementations as you wish in an appropriate forum related to RPM, not PLD. 73 de Jeff _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
