[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What Fedora makes sucking for me - or why I am NOT Fedora



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 gmail com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]