Re: Packages with "fc6" name in Fedora 7

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

 



On Wed, Apr 11, 2007 at 01:43:01AM +0530, Rahul Sundaram wrote:
> Panu Matilainen wrote:
> >On Sun, 8 Apr 2007, Rahul Sundaram wrote:
> >
> >>Hi
> >>
> >>The current thinking seems to be to just ignore them* but this is 
> >>guaranteed to result in a lot of confusion. When end users do a 
> >>distribution upgrade via yum or Anaconda, some of the packages might 
> >>not have been updated to the Fedora 7 version due to incorrect 
> >>packaging or other issues while the rest are packages which are 
> >>deliberated not rebuild to avoid churn. Debugging a end user system 
> >>with such a mix of packages is very painful.
> >
> >Dist tags considered harmful... :) RHEL 5 suffers from this same 
> >syndrome, it has loads of packages tagged "fc6" which I could imagine 
> >causing quite a bit of confusion as well.
> 
> Since you ask, this is one of the main reasons I said it is guaranteed 
> to cause confusion. If anybody can calculate the amount of money Red Hat 
> loses in having support people attend to such issues I would doubt they 
> would consider it merely a cosmetic issue anymore.

consider the amount of money spent on developer time when a one-liner
security fix applied to an old never-rebuilt package makes it boom at
run-time.

And forget about RH's money, since some people yell, that this is not
RHEL we're talking about - the same applies to F7: Nobody guarantees
that a rebuild of foo-1.2.3-4.fc6 on F7 would give you a working
package.

For example bridge-utils was built under FC6 against a 2.6.18
kernel. If it uses ioctls or any /proc interface that has been
deprecated in 2.6.19 and will be obsoleted in 2.6.21, then it will
explode w/o a warning during F7 maintenance time. While a rebuild now
would have a chance to spitt some deprecated warnings onto the sceen
on usage.

The above example is constructed, while bridge-utils is indeed built
at the _beginning_ of FC6 and indeed has a BR of kernel-headers,
e.g. a completely different build environment than it would have today
in F7, whether the kernel API changed in the bridging area would have
to be checked, most likely nothing happens.

But there are quite a few other packages that were built against
ancient kernel-headers, and glibc form FC6 to F7 also has some changes
that may or may not break things, especially some kernel 2.4
interfaces upgraded to 2.6, so any software that was built against
these interfaces may simply break at runtime (I think it was
sys/personality, but anyone who cares should really simply diff FC6
and F7 glibc include files to get an idea of the differences of 2.5 vs
2.5.90).

The fc6 tag is really cosmetics in comparison to what we may run into
w/o a proper rebuild. In fact we should really keep them (the tags),
so when a package explodes the user/bug reporter/bug assignee will be
able to identify the distribution the package was built on and perhaps
derive that that's the real issue.

So my recommendation on the subject is:

a) always do a full rebuild at a specific point in the release cycle
   (until now FC did rebuilds of 95-100% and FE of 100%)

b) If the above is not wanted, then keep the disttags as is so that
   the "age" of the package or, better said, its the build environment
   can be estimated.

You can find more examples and background, as well as rebuild
statistics on the fedora-packaging list, but please keep the
discussion here.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpjweZAflGeK.pgp
Description: PGP signature

--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly

[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux