Am Sonntag 14 Dezember 2008 22:11:26 schrieb Tobias Powalowski:

...

Hi guys, new kernel adresses the following things: - bump to latest version

please signoff for both arches,

greetings tpowa

Are you sure those files should be in the package:

kernel26: /lib/modules/2.6.27-ARCH/modules.alias.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.dep.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.symbols.bin existiert im Dateisystem

Am Montag 15 Dezember 2008 schrieb Pierre Schmitz: hrm you are right those files are new. Which package do your files belong, which already exist? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Tom K schrieb:

No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.

I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.

That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated. After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate.

On Mon, Dec 15, 2008 at 1:32 PM, Tobias Powalowski wrote:

Am Montag 15 Dezember 2008 schrieb Thomas Bächler:

...

Tom K schrieb:

...

No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.

I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.

That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated.

After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate. Are you guys fine with moving kernel package to core, with this possible file conflict and make a announcement that forcing is ok?

Yeah, just make sure we indicate that users should -Sf kernel26, not -Sfyu, which would be a poor recommendation on our part.

On Mon, Dec 15, 2008 at 2:41 PM, RedShift wrote:

Why not solve it the right way, by creating a correct package?

I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files. What "correct package" are you suggesting?

On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote:

On Mon, Dec 15, 2008 at 2:41 PM, RedShift wrote:

...

Why not solve it the right way, by creating a correct package?

I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.

What "correct package" are you suggesting?

As these files are generated by module-init-tools whenever it is run for your kernel, why not solve this using post_* functions? Whenever the kernel gets installed/upgraded, depmod is run from post_install/upgrade. Whenever the kernel is removed, the files created by depmod for this kernel get removed from post_remove. Shouldn't be hard to do, the result is the same and no file conflicts will exist. BTW: Please remove the -v flag from depmod in kernel26.install, it's stupid to make depmod print verbose messages while redirecting output to /dev/null.

On Sun, 2008-12-21 at 09:48 +0100, Tobias Powalowski wrote:

Am Dienstag 16 Dezember 2008 schrieb Jan de Groot:

...

On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote:

...

On Mon, Dec 15, 2008 at 2:41 PM, RedShift wrote:

...

Why not solve it the right way, by creating a correct package?

I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.

What "correct package" are you suggesting?

As these files are generated by module-init-tools whenever it is run for your kernel, why not solve this using post_* functions? Whenever the kernel gets installed/upgraded, depmod is run from post_install/upgrade. Whenever the kernel is removed, the files created by depmod for this kernel get removed from post_remove. Shouldn't be hard to do, the result is the same and no file conflicts will exist. Well depmod is already called in .install file. Why to make a remove in PKGBUILD and create untraced files on the system? This bug affects only people who run testing and installed new external modules. This should be not a big part of the community, mostly noone runs testing ;)

...

BTW: Please remove the -v flag from depmod in kernel26.install, it's stupid to make depmod print verbose messages while redirecting output to /dev/null. fixed

Before releasing .10 kernel I would like to have a clear answer on how to handle this. My suggestion would be the --force option, the other thing is a workaround which is imho not needed here.

If someone runs testing, they better be able to figure out "pacman -Sf kernel26", especially if we make posts about it. I'm anxious for 2.6.27.10, it's supposed to fix my hibernate regression. Dale