On Wed, 2007-09-19 at 08:20 -0500, Les Mikesell wrote: > Andrew Kelly wrote: > > >>>> That's almost the model that I foresee actually working for whatever > >>>> unix-like system implements it first. Make the package manager just a > >>>> bit smarter and add a 'publish' button somewhere so a person who had > >>>> configured a nicely working system could export his installed package > >>>> list and custom configuration settings, and it would result in a URL > >>>> that anyone else could click to duplicate that setup slightly more > >>>> closely than matching kickstart installs would. That way someone could > >>>> tweak a machine to someone like Mossberg's satisfaction, he could push a > >>>> button, and the next day a million people could be running "Mossberg's > >>>> recommended Linux". Or the same for someone who actually knows how to > >>>> configure a linux box... > >>> Outstanding idea, Les. You know if anybody is currently working on > >>> anything like that? > >> No, everyone wants to make up new distribution names, spin CD's and > >> build incompatible repositories instead of cooperating and making a > >> package manager smart enough to do this. > > > > Oh, you're talking about a completely new package manager. I thought you > > just meant something standalone which would/could export a config, > > basically building a better mousetrap in a kickstart sense of things. > > That's a start - I'd probably do an extremely minimal kickstart install > followed by a yum install of a complete packagelist generated by some > invocation of 'rpm -q' on the master machine. But the install isn't > quite the point. I want to be able to track subsequent changes on that > master machine over the next many years at whatever interval the admin > exports updated lists, and I want to be able to switch to duplicate some > different master at any time. Right off the top of my head, I don't see this playing out without a complete restructuring of repositories. Read that to mean that packages (be they .deb, .rpm, .nameTheNewAnimal, whatever) are going to have to have a new naming convention. Every repackaging is going to have to be uniquely identifiable and (more importantly) indefinitely available. Your "master" machine is also going to have to take on the burden of accuracy in minutiae. It will have to maintain a local DB of diffs on its config files vs the packaged config files and export that material as well so that any non-default local changes are also duplicated. And of course any locally compiled source installs will have to be part of the kit. > Yum could almost do this, given repositories containing all of the > needed packages/versions but would need some help in terms of rolling > local config changes on the master into some sort of packages and > dealing with which packages and config items are really local (hostname, > ip address, etc.), which are hardware related, and which can be > duplicated. In my opinion, local/hardware/software-virtual settings > should never have been put in the same files to start with, but... Yes, guess I could have read that first and saved re-stating the obvious. sheesh. ;-) > > Whatever. I'm in, either way. > > I've been looking for something of that magnitude as an anchor project > > in a long-term thing I'm currently conceptualising. > > The big problem would be having a stable repository containing all > needed packages in all versions that might be referenced by any > packagelist and a place to upload the master lists. That's just logistics. The booger will be the two outermost points of the relationship: the "export" and the "import". > > You in, too? Or are you in more of a "peel me another grape" place right > > now? > > I'm not in a position to write a lot of code or provide the repository > space, In all honesty, neither am I in the current near and mid-term. I may have opened my yap a bit wider than it could actually accommodate. But it's certainly something I'm going to pursue eventually. > but I've sampled a lot of grapes and can comment on which are > suitable for general consumption. Ach, that particular pool is thousands deep. There'll be no end to the flow of useful and well-meant input. > Personal opinion again, but the thing > that makes unix-like systems unsuitable for personal desktop use is that > there is just too much administration involved if everyone has to do it > all individually - and a few dozen expertly installed/maintained systems > could handle virtually everyone's desktop needs as long as the ability > to add new packages is still available. I see your gist here, but it's all really relative, innit? I mean really, the lion's share would love to have a manservant to dress them everyday, but most of us dress ourselves, non? Most of us do it by necessity, of course, but there are not a few who do it by choice alone. I disagree that there is too much admin involved. Personally, I choose to be in this namespace precisely because of the admin. The market is saturated with TSFOS (The Spoon-Fed Operating System), and I am tickled to have an OS available to me over which I can have total control. I'm likely in a rather small minority, but I have no interest in "driving your car" so to speak. There might be certain aspects of somebody else's installation which would interest me, but I could never envision myself wanting to have the exact set-up as Bob or Larry or Whomever. > But "maintained" is the > operative word there - when the master updates or changes package > versions the copies need to track the changes over the life of the machine. Another can of worms at the consuming end would be the issues of staying up to date versus some kind of point-in-time cloning. Andy
