Andrew Kelly wrote:
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.
There would be limits, but I think it would be possible using the way
the Centos repositories work within the span of a release - which is
pretty long. The version-numbered packages just accumulate although they
periodically shuffle old updates out to an archive repository. However
I'd probably investigate the features of rpath's conary package manager
before re-inventing anything. I haven't really used it yet but it
sounds more comprehensive than the others.
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.
That's the point of this exercise. Getting details right is something
that computers are supposed to be good at. Keep in mind that without
this system thousands (millions?) of people are doing this work by hand
and probably getting much of it wrong.
And of course any locally compiled source installs will have to be part
of the kit.
I'd expect packaging to be standardized and if a master required
packages or versions not in the stock repository an additional
repository would be provided to hold them. They would be packaged and
installed from the package onto the master. Remember, we are expecting
an expert to be configuring the master, so we'll expect this to be done
right.
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".
Have you looked at rpath's appliance builder? The builder portion isn't
free but I think the rest of the tools are. And automating the initial
build isn't quite the goal. It should be to roll out working clones of
an expertly hand-built system and do all subsequent maintenance.
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.
I have the experience of actually keeping hundreds of machines working
over many years, though. I don't know everything, but I know some
things that work, and a lot that don't.
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.
That's not a great analogy. Unix was really designed to be used in a
multiuser situation where a site administrator would be expected (and
needed). Back when computers were expensive, that made sense. The
problem is that administration hasn't gotten any easier now that
everyone can afford their own machine but not an administrator.
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.
I'm not talking about driving a car, I'm talking about customizing a car
which might sound like fun but very few people really want to do it
themselves. Even if the car factory has an updated part for their car,
most people will let the dealer bolt it on instead of hoping they get it
right themselves without any prior experience. You aren't a typical
computer user, though. Think of it the other way around. Could you
build a system that would be suitable for Bob/Larry for some particular
use, and if it is good for them, how many other people might it suit?
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.
Apple probably has the most popular unix-based desktop around. It isn't
quite comparable to Linux in that they limit the range of hardware. But
consider this feature: if you buy a new Mac, you can connect it to your
old one via firewire and it will migrate over all of your old accounts,
settings, and data. Note that this works even across different
processor types. For example it will migrate the ppc version of MS
office to an intel mac along with all the files, and it will run there.
That's probably too much to ask for Linux but automatic migration
within a processor type line seems reasonable. And if you can do it
once, you should be able to repeat it any number of times for things
where the license allows.
--
Les Mikesell
lesmikesell@xxxxxxxxx
