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

[Les Mikesell]

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