[CentOS-devel] Delta RPMs disabled by default?

[Les Mikesell]

On Fri, Jul 11, 2014 at 5:42 PM, Nathanael D. Noblet <nathanael at gnat.ca> wrote:
> >>
>> But that would be exactly the thing I'd need to control  - and I don't
>> want to control it by having to know anything about the packages ahead
>> of time.  For example updating to versions between java1.7u25 and
>> 1.7u55 would have broken an elasticsearch cluster.  But I wouldn't
>> have known that ahead of time to use any top-down control.  I want to
>> control it by taking a known-good instance, built/tested by some group
>> that knows the details of the component they develop best, and be able
>> to duplicate that system as exactly as possible (allowing for
>> hardware/network/etc. differences), updating some subset of production
>> boxes at a time over some timespan.
>
> Hello,
>
>   So I haven't fully followed the thread and thus may not be helping.
> However I think what you are looking for is called ostree. I have never
> personally used it but I think it fills the niche you are looking for
> which is a broad set of testable updates. No idea of the pros/cons but
> may be what you want to look at.

I had a long discussion with someone else about ostree, but it all
seemed to be oriented around telling it specifically what package
versions to install and test before it can duplicate it for
production. And I think it needed a snapshot of the packages for each
state.  I want something to reverse-engineer the working system and
tell the others to get the same package versions from the usual
places.  We generally have lots of different versions of things with
lots of different overlapping releases and I don't want to manage
intermediate snapshot copies of entire systems or repositories in all
of the possible states I might want to reproduce.   It's not that it
couldn't be made to work, just that it seems like all you should ever
need is the list of versioned package names.  Or better yet, a
timestamp of the latest package version you want to update to.

-- 
   Les Mikesell
      lesmikesell at gmail.com