On Mon, 2007-08-06 at 07:30 -0400, Bryan J. Smith wrote:
> I think YUM's speed is over-demonized. At most, I wish there was an
> option to discretely decide when to sync with the repositories, like
> in Apt. And there are other considerations too.
Okay, let's switch gears _away_ from the "home consumer" aspects and
start looking at Fedora's _real_ value at enterprises. Like it or not,
Fedora is the staple of not only RHEL, but it's core technologies are
what enterprises deploy.
- What enterprises would like out of YUM (at least my experience)
Expanding on the "discrete" comment, I once implemented a simple set of
Bash scripts to maintain elementary versioning in YUM repositories. I
did it because I wanted to get away from using separate repositories.
At the same time, it was backward compatible with normal usage. My
Bash-based hack wasn't integrated with the YUM client itself, but there
is no reason it can't be.
- Ultra-simple ECM in the repository ...
>From Fedora's standpoint, keeping updates, updates-testing, development,
etc... in separate repositories makes sense. But in an enterprise, it
just does not. I want to have my enterprise configuration management
(ECM) in the same "release" repository. I want to be able to go back to
any state of the repository by ...
- Revision (incremented each time the meta-data is re-created)
- Time (merely uses the latest revision available at that time)
- Tag (label on a revision for easier usage)
This can be done 100% with the meta-data and is rather simple (with one
YUM-RPM caveat, see below). You simply have multiple meta-data files
with a revision appended -- e.g., ".(rev)", as well as a single file
with a list of all tags, e.g., ".tags". Or, to be even more advanced,
you can leverage RCS by having a single ",v" file -- which stores all
revisions as well as tags. For backward compatibility, the latest is
always the normal meta-data filename(s) of the repository -- in the case
of a RCS ",v" meta-data file, it would be the "checked-out" version.
- What this buys enterprises?
I can now mix my "testing" of new package roll-outs (possibly under
integration and/or regression test) with my "early adopters" as well as
the "default, lateset release." I also may have different departments
or projects on different "releases" and those could also be tagged,
without having to build symlinks/hard link scripts, among other things.
But most importantly, this is _not_ a difficult hack. I'm not talking
about advanced configuration management, I'm talking about ...
o Maintaining a history of meta-data revisions in the repo tools
(either individual files or a RCS ",v" file)
o Maintaining a set of tags to those revision files in the repo tools
(again, either a tag index file or its in the RCS ",v" file)
o Having YUM clients being able to fetch by revision, date or tag
(revision is easy, date resolution to revision is easy,
and tag is easy)
And for backward compatibility with older, "pre-ECM YUM", the repo tools
throw out the standard meta-data file(s).
- The one YUM-RPM caveat / limitation
Now the one limitation is that you can't get "clean reverts" and people
would need to be aware of that. I.e., if you're system is already at
revision 49, YUM-RPM is not going to be able to take you back to
revision 47 automagically, you can only go forward -- at least
"cleanly." Otherwise would require heavy modification to YUM-RPM, at
least from what I've seen. I'm not advocating that effort (although it
would be nice in the future -- and one reason I like Smart's, although
limited, features here), so I'm not looking for anyone to bother.
I'm only talking about offering updates by repository ...
- Revision
- Time
- Tag
Based updates, of at least the current revision or later of the system.
If someone is at revision 49 and they try to update to revision 47, or a
date or tag that is before revision 49, then it doesn't allow that. I
don't like maintaining separate repositories for the same set of ECM
releases, often in the flow of "integration/regression" testing, "early
adopter/tester" and "main release" -- as well as being able to setup an
older state of the package repository that was a "known, good quality."
--
Bryan J. Smith Professional, Technical Annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
--------------------------------------------------------
Fission Power: An Inconvenient Solution
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
