James Antill wrote:
I don't think that's the only sane way to do it,
And yet you haven't illuminated what those other sane ways are.
I thought I did.
but it is the most
obvious and adding a simple mechanism to yum to report the latest update
timestamp or some repo transaction id(s) that could be fed to another
instance to ensure it ignored subsequent changes to the repo(s) to
perform an update to the same packages would be useful in its own right
and appreciated when inherited by the enterprise versions.
What is this "repo. transaction ids"
If you tracked changes in a repo, yum could use that to ensure that it
didn't pull newer packages when you were trying to reproduce a tested
update.
... how is that different from a
local mirror. Even better question how is it _better_.
Ummm, it saves every user a boatload of work and disk space... More to
the point it is something that they might actually do.
Everyone who spends five minutes thinking about it comes up with "I
know we'll merge the functionality of git and yum, so that you can
follow branches in a repo. etc." ... which _might_ be fine, if _they'd_
actually have to implement it. But I fail to see the significant
advantages over doing all of this work on the repo. side (and possibly
creating tools there, to help -- again, feel free to if you want this).
Yes, it is clear that you need version control capability in a package
manager. And it is equally clear that yum doesn't provide it. So some
simple workaround is necessary. Ultimately, I'd love to see git or
subversion managing the list of package names _and_ all locally modified
config files, but a first cut could be just a planned, sane way to
reproduce a tested set of packages since everyone knows that fedora's
repos have their good days and bad days. _Any_ way to keep untested
packages on a test machine and exactly the tested set on production
machines is better than none. We aren't talking about people who will
test and people who want someone else to do it - I mean this for people
with more than one machine, where some actually have to work every day.
However Fedora only has the latest, so the only real
alternative is creating a new repo. of somekind ... at which point you
might as well just do a local mirror.
Fedora has this split personality about wanting to be both
production-usable and also the leading edge where new code first meets a
lot of new situations. You can't quite be both at once.
Those features are not binary flags, they are a line with
RHEL-2.1/CentOS-2.1 on one end and rawhide on the other. There are a lot
of points on that line and Fedora serves some of them well.
That's not what I mean. There are days when what you get mostly-working
code in a fedora update and days you don't. I'm not talking about
rawhide or RHEL,. just about what happens when a large number of users
run something new for the first time which is what happens in fedora.
However, it
could actually pull it off if there were a way designed in to avoid some
of the bugs pushed out in updates on critical machines.
By "avoid some of the bugs" I'm going to assume you mean "I want other
people to do work" ... which is nice, but not how it works.
No, I have said I would do much more testing if given a design where I
knew I could subsequently update a working machine to exactly the same
set of packages I had tested. I'm just not willing to mirror a whole
repository to deal with this on my own.
Asking every
user to maintain a full repo mirror just doesn't sound like a reasonable
approach to this though, especially if you think the mirrors themselves
would have a problem storing all the updates.
I'm not asking "every user" to do that. Let me show you this full
conversation, and hopefully it will be obvious:
. LES: I need to do X.
You misunderstood. I'm not prepared to be the only tester. I mean "if
you do X, many more people will test". Basically everyone who runs
fedora needs to do X unless they can afford to be down a while.
. JAMES: To do X you need a local repo.
. LES: Asking every user to maintain a local repo. isn't reasonable.
OK, asking any user to maintain a local repo isn't reasonable. I'm not
going to do it anyway. And expecting a lot of people to do it is less
so, along with expecting any users to be able to test package sets they
can't reproduce.
It could be as simple as batching updates: suppose everything but
critical security fixes and corrections for known-bad updates only
updated every few weeks, and the user could could choose (with a
permanent option) whether any particular machine should update on the
leading or trailing edge of this window.
We already have updates-testing and --security, --bz. Which basically
do this ... if you think things should stay in updates-testing longer,
propose some reasoning to FESCo/whatever.
Making updates become updates-testing2 based on an opaque time window
is not the solution though, IMO.
Why is the time window opaque? Again, why do you expect anyone to test,
whether from updates-testing or elsewhere without a mechanism to use
exactly the package set that they tested on their working machines?
Or, pick a time frame reasonable both for mirrors to hold updates and
for users to complete testing (2 months?) and only remove packages after
their replacements have reached that age.
Have you spoken to anyone about how much data that would be, and how
much the mirror admins would like/want it? This is the fundamental
problem with keeping all the data for old updates ... the mirror admins
don't want to commit.
If you have a local need for it though, you can presumably afford the
resources.
I don't have a local need for it other than testing fedora, which, if it
can't be done without maintaining more disk space than the people in the
business of maintaining mirrors can handle, I'll just ignore.
Or, what if one machine's yum automatically acted as a proxy for
another's update, perhaps with an error generated if the package hadn't
been downloaded already and if you want to be even more helpful, a
warning if none of the code from a package had been run on the
intermediate machine?
You want a specific collection of packages to be exported for other yum
clients to use ... we have this, it's called a repo.
No, a repo is where you put new packages in. A cache is where you get
ones you've gotten before. One instance of yum acting as a proxy cache
for others would be a minimalist solution, since yum already knows how
to cache and how to use a proxy.
That way you'd get local mirroring of just the
desired packages without extra work anywhere - in fact you'd get both
repeatable updates and a load reduction on the mirrors out of it.
A mirror that is different from it's upstream repo. _isn't a mirror_.
Yes, you can create a local repo. using data from a remote repo. as
it's basis ... but unless it's identical (within a limited timeframe)
then it isn't a mirror.
I don't want a mirror of a revolving door repo. I want a reproducible
update. The mechanism is sort-of irrelevant.
It's
probably possible to do this now with a lot of extra steps. Nobody is
going to do it unless it is one step and looks like a cleverly planned
design.
It kinda works right now, with Fedora, because Fedora doesn't sign the
repomd.xml or use metalinks to validate the repomd.xml ... both of those
things will change in Fedora 11 (and metalinks can be used now). At
which point yum will reject a mirror which isn't.
I don't want a mirror, I want a cache. And yum had better keep working
with proxy caches.
Or, design a working solution to back out broken changes. The only one
I'd trust would be to install with a spare system partition that is
synchronized with the active one just before an update and used as an
alternate boot for a fairly drastic fail-back mechanism. And even that
won't work where file formats of things in other partitions are modified
in an update.
Yeh, good luck with that, but it's far from a yum problem if you want
to follow that route.
One way or another, if I were building a distribution that wanted to
simultaneously claim that it is both new code and 'tested and working',
I'd try to plan in a way that it wasn't a flip of the coin on every
machine which you'll get today.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
