Fedora 13 installs *.fc12 packages. Why?

[blnlx]

I just installed Fedora 13 and I'm installing additional packages with yum. I was surprised to see that some of the Fedora 12 packages are installed as well. For example "yum -y install unison" results in:
Dependencies Resolved
================================================== ==============================
Package Arch Version Repository Size
================================================== ==============================
Installing:
unison227 i686 2.27.57-13.fc12 fedora 622 k
Installing for dependencies:
xorg-x11-fonts-misc noarch 7.2-9.fc12 fedora 5.7 M

Transaction Summary
================================================== ==============================
Install 2 Package(s)
Upgrade 0 Package(s)

Total download size: 6.3 M
Installed size: 9.1 M
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 6.3 M
(1/2): unison227-2.27.57-13.fc12.i686.rpm | 622 kB 00:01
(2/2): xorg-x11-fonts-misc-7.2-9.fc12.noarch.rpm | 5.7 MB 00:13
--------------------------------------------------------------------------------
Total 417 kB/s | 6.3 MB 00:15
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : xorg-x11-fonts-misc-7.2-9.fc12.noarch 1/2
Installing : unison227-2.27.57-13.fc12.i686 2/2

Installed:
unison227.i686 0:2.27.57-13.fc12

Dependency Installed:
xorg-x11-fonts-misc.noarch 0:7.2-9.fc12

Complete!

If I'm not mistaken *.fc12 is Fedora 12 package.
How is it possible that Fedora 12 package is installed in Fedora 13?
Are these compatible?

[tho.mei]

Yes, this packages are compatible. If nothing has changed F13 uses F12 packages.
Have a look at: ftp://mirror.switch.ch/mirror/fedora/linux/releases/13/Everything/i386/os/Packages/ there are a lot of F12 packages.

[AdamW]

Yep, nothing unusual here. Packages are not rebuilt if nothing changes in them and no external changes require them to be rebuilt.

[blnlx]

Thanks, it's good to know.

Just out of curiosity I checked some statistics. This is the outcome:

ftp://mirror.switch.ch/mirror/fedora/linux/releases/12/Everything/i386/os/Packages/
0x fc8 packages
5x fc9 packages
5x fc10 packages
120x fc11 packages
15003x fc12 packages

ftp://mirror.switch.ch/mirror/fedora/linux/releases/13/Everything/i386/os/Packages/
0x fc10 packages
36x fc11 packages
5143x fc12 packages
11466x fc13 packages


Interesting :), I also understand now why I didn't notice this before with Fedora 12.

[AdamW]

We did a complete rebuild for F12 because there were major changes to glibc, gcc and something else (I forgot what) which warranted it. For F13 there weren't any major ABI/API changes to fundamental components like that, so there was no need to do a complete rebuild.

The only pre-fc12 packages in F12 are ones which failed during the mass rebuild for some reason.

[itachi]

We did a complete rebuild for F12 because there were major changes to glibc, gcc and something else (I forgot what) which warranted it. For F13 there weren't any major ABI/API changes to fundamental components like that, so there was no need to do a complete rebuild.

The only pre-fc12 packages in F12 are ones which failed during the mass rebuild for some reason.

Sorry, if I hijack this thread a bit, because it's somehow related to the complete rebuild in combination with glibc.
My problem is, it seems that I can't get programs to run using c functions in the string.h header (maybe more than string.h, but at least .. all str<whatever> functions are b0rked).
This seems to happen since my last distupgrade from F11 to F12 via yum.
Example Program (I think this was from a book as a bad programming example for security oriented software ..nvm).

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/syscall.h>
#include <syscall.h>
#include <unistd.h>
#include <stdlib.h>

char correctPassword[100] = {"correct"};
const int BAD_PASSWORD = -1;

int main (int argc, char * argv[]) {
char userEntry[12];
gets(userEntry);
if (memcmp(correctPassword, userEntry,strlen(correctPassword)) != 0) {
printf("password wrong");
return (BAD_PASSWORD);
}
return 0;
}

I compiled it with:
gcc -g badpassword.c -o badpassword
and when I execute it, i get the following message:

./badpassword: Symbol `strlen' causes overflow in R_X86_64_PC32 relocation

Segmentation fault (core dumped)

Google didn't really reveal the cause of this problem. Maybe you have an idea?

[AdamW]

I'm not the guy to ask, I don't code. =) Sorry!

[Roland Deschain]

Sorry, if I hijack this thread a bit, because it's somehow related to the complete rebuild in combination with glibc.
My problem is, it seems that I can't get programs to run using c functions in the string.h header (maybe more than string.h, but at least .. all str<whatever> functions are b0rked).
This seems to happen since my last distupgrade from F11 to F12 via yum.
Example Program (I think this was from a book as a bad programming example for security oriented software ..nvm).
I compiled it with:
gcc -g badpassword.c -o badpassword
and when I execute it, i get the following message:

./badpassword: Symbol `strlen' causes overflow in R_X86_64_PC32 relocation

Segmentation fault (core dumped)

Google didn't really reveal the cause of this problem. Maybe you have an idea?

I read some threads about there having been known problems with memory ops in early 4.x versions of GCC.

Your test program compiled and executed perfectly on two different FC13 (x86_64) machines of mine, although both threw compiler warnings that the gets() function is dangerous and should not be used.

Both my systems (one is AMD, one is Intel) have GCC v4.4.4-2 installed...both were clean FC12 installs that I upgraded via yum. GCC is the first place I'd look if I were you.

Out of curiosity, what happens if you hardcode an integer value for the third argument to your memcmp() function call, instead of using the strlen() function?