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
