On Fri, Apr 4, 2014 at 11:42 PM, Les Mikesell <lesmikesell at gmail.com> wrote: > > No, I don't see the point. RPM packages are already a reasonable > distribution format. Why not use them as is? For one thing, you pay the cost of dependency resolution, downloading the entire repo metadata (in the case of Fedora, it's 18MB) per client. It doesn't make sense to have a cluster of 1000 HPC nodes that you want to be identical each run through a satisfiability solver. Or down to embedded devices - think cash registers. Furthermore, the "pure replication" OSTree model enforces that the trees are *identical*. It's fully atomic - if you pull the power, you either have the old system or the new system. Achieving this on top of the traditional package model requires significant re-engineering around how the installation and things like %post work. This doesn't mean that the traditional yum/apt-get model is bad - but I think the rpm-ostree model also makes sense for some use cases. It's going to get a lot more interesting once rpm-ostree supports package installation on top, then you're close to the best of both worlds. (This requires the significant re-engineering mentioned above). > 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. I see. Hmm...but can you track multiple lists? Probably not, you'd get into a conflict mess. Repositories of course are already package sets - things like comps groups (or metapackages) are the "list" aspect. There's also Software Collections and Docker which allow parallel installation. I understand your idea, but it feels like the above technologies overlap with it substantially. > If yum/rpm aren't good enough to maintain machines they should be > fixed, not forked. I wouldn't call ostree itself a fork of anything. > You just need something to get to the point where > yum works and the ability to track versions and deletions. I'd say it works today! It has a known quantity of strengths and weaknesses. "yum history" does track versions and deletions. The hard part is addressing the weaknesses without breaking it =) Now, rpm-ostree when it supports package installation on top will definitely compete with traditional package tools like yum, that's true. But the trajectory in Fedora was already towards dnf which uses new libraries like libsolv, hawkey, and librepo, that rpm-ostree will use as well.