On Sat, Apr 5, 2014 at 8:29 AM, Colin Walters <walters at verbum.org> 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. OK, I don't mind my machines doing some work. But if you didn't, couldn't you push that part to a server with traditional caching of query results? And given that the point is to duplicate an existing system the dependencies would already be known/solved anyway. > 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. Maybe... I can't think of a machine that can do useful work that couldn't compute its own dependencies, though. > 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. If you need that, you are probably already block-replicating. But how do you deal with the necessary differences in that case? There is always some ugly overlap in software/system/local configuration that is hard to abstract away. >> 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. If there is no need to learn a new and complex configuration tool, anyone could produce the lists - so there would almost certainly be one created for most useful configurations. > 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. And yet none of them give you the ability to build/test one system, then let someone else duplicate it easily and track its tested updates. Which is what pretty much everyone needs to do if they have multiple machines, and it would give people with no administration experience the ability to have machines with software managed by experts, almost for free. >> 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. Well, if it doesn't use the same command structure and repositories to install software I call it a fork. Unless it is going to become the only way to install software. >> 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 =) I doesn't work for me - now. > 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. Yes, Fedora always seems to start with the idea that everything that anyone already knows how to use is wrong and needs to be replaced. But I don't see the point of having a new abstraction that you have to know in order to build a system and then reproduce it - which is essentially just repeating the same thing. I'd like to see something that lets you build/test organically with traditional commands, then publish the configuration in a way that can be re-used on top of existing distribution infrastructure. In fact I've always thought that that should have been the goal of package management from the time computers became cheap enough that someone might own two of them. And it should be particularly obvious to people working with version control at the source level that you would want the same ability to duplicate and track someone else's revision exactly for the binaries too. But instead, there are many arcane abstractions that try to make it possible but that always involve leaning different concepts and building different infrastructure to make it work, and crazy things like making your own mirror of a repository just to control the versions available to yum - for every state you'd want to reproduce. Stuff that no one would do to make one simple, working copy of someone else's known-good system. -- Les Mikesell lesmikesell at gmail.com