Package EVR problems in Fedora 2007-10-31

[Michael Schwendt]

On Fri, 02 Nov 2007 13:42:55 +0100, Ralf Corsepius wrote:

> C'mon, you are once more trying to push people to adopt your (IMO:
> broken) vision.

Ridiculous.

Actually, it's the opposite. I'm not the one who's fighting the use of
scripts like upgradecheck, just because some of its (not even daily)
mails are considered an annoyance by a few package maintainers. Take a
deep breath, mash warns about broken deps in rawhide every day, even
when a packager can only wait for another packager to fix something
first.

It's not even my script (except for contributions). If some committee
rules that the script must not be run anymore because packagers complain
about it, I've learnt to not care anymore. I draw my conclusions and
move on. Why spend time on stuff that's not appreciated?

But I distinguish between people, who think about improving the checks
(or who suggest improvements), and people who put most of their energy
into pointing out there negative views. Previously, when F7
updates-testing became mandatory, more maintainers have requested to
not ignore updates-testing in the checks.

Some of the scripts have saved many a packager's ass -- and more than
once. Broken upgrade paths have caused nasty soname/deps breakage
during dist upgrades before.

> - If a package is being pushed from testing to updates (currenly not
> possible due to bodhi's design),

?? What do you mean? How have the many packagers done it? Marking a
test update "stable" does work, doesn't it? Do you see a pattern in
the way you criticise achievements? You focus on any flaws you see,
totally ignoring the positive rest that has been real progress.

> Example: "Package X works in FC-8 but doesn't work in FC-7".

If it works, why isn't it put into F-8 (or devel)?

I can answer that for you.

Case 1) The usual procedure is that the packager still focuses on F-7
and does not use F-8/rawhide yet. The update is prepared for F-7 only,
neglecting F-8/rawhide completely.

Case 2) The usual %{?dist} and "make tag" breakage. Wrong release
bumps as the cause of broken upgrade paths.

Case 3) You refer to an already released pkg in F-7 and F-8, which is
reported as being broken in F-7 only. Let's assume you prepare a
version upgrade as a test update for F-7, not testing the same code
for F-8 or devel. You try to cherry-pick your target audience by
releasing an exclusive test upgrade for an old(er) dist, neglecting to
test the same stuff for the newer dists. What is so wrong about
warning about the broken upgrade path? Especially when you learn
that the test update works for F-7, you need to bring F-8 and devel
on par with F-7 anyway.

> => People start addressing the FC-7 issue by building packages for FC-7
> and want their FC-7 audience to test their attempts. FC-8 is completely
> irrelevant at this point.

It isn't, because if the test environments are so much different that
one dist malfunctions while the other doesn't, you need to test the
updates for both dists and not just for one. 

--- WARNING ---

Just for Ralf, the next upgradecheck report [send to this list only]
will exclude F-7 updates-testing. Have fun drawing *your* own
conclusions. :-/