On Fri, Apr 4, 2014 at 6:28 PM, Colin Walters <walters at verbum.org> wrote: > > >> - and be able to follow the updates after they have been >> installed/blessed on the master. > > Right. > >> This looks close, but not quite... >> I think there should be a list of repositories that maintain the >> packages in all the referenced versions, > > I'm not quite sure what you're suggesting here. There are two kinds of > repositories: yum and ostree. When you say "maintain the packages" are > you talking about "treecompose", i.e committing a set of RPM packages > to an OSTree repository? No, I don't see the point. RPM packages are already a reasonable distribution format. Why not use them as is? The missing part is just the inability of yum to reproduce a known working set of package versions on its own. >> and the main part would just >> be a version-controlled package list and maybe some diffs/patches to >> configurations. > > Right, that's what > https://github.com/cgwalters/fedora-atomic/blob/master/products.json > boils down to - it's a list of trees, each of which are composed of a > set of packages. > > https://github.com/cgwalters/fedora-atomic/commit/cb3b741616b5d11a00950e8f616c03f998bd474d > > is a sample commit that added rpm-ostree to the trees shipped on each > client. > > Another example is that if I decided tmux was awesome and everyone > should have it, I could push: > > diff --git a/products.json b/products.json > index ed99ccd..41133e9 100644 > --- a/products.json > +++ b/products.json > @@ -23,7 +23,8 @@ > > "packages": ["kernel", "rpm-ostree", "generic-release", "lvm2", > "btrfs-progs", "e2fsprogs", "xfsprogs", > - "rpm-ostree-public-gpg-key", "gnupg2"], > + "rpm-ostree-public-gpg-key", "gnupg2", > + "tmux"], > > "postprocess": ["remove-root-password"], > > > Conversely, I could remove it later, and it would disappear from the > trees, and then vanish when client machines ran "rpm-ostree upgrade". > This is a huge difference from traditional package management per > client, where packages normally linger on unless explicitly removed. That's not at all what I had in mind. I'd like to see something where you just install a suitable set of packages on your own machine and run some program that publishes the list of package/versions you have installed. And the matching client takes that list and feeds it to yum. With repos that retain the packages as long as any published list references the package version - preferably with DNS round-robin instead of mirrorlists, so local proxy caches work sanely. Season with something to diff/patch local modifications into configs and you should have reproducible machines. If yum/rpm aren't good enough to maintain machines they should be fixed, not forked. You just need something to get to the point where yum works and the ability to track versions and deletions. -- Les Mikesell lesmikesell at gmail.com