[arch-dev-public] When to remove provides/conflicts/replaces?
Hi, Do we have any guidelines on when to remove the provides/conflicts/replaces arrays from a PKGBUILD? In other words, what is the oldest system we support updating from? Allan
Am 13.06.2010 12:43, schrieb Allan McRae:
Hi,
Do we have any guidelines on when to remove the provides/conflicts/replaces arrays from a PKGBUILD? In other words, what is the oldest system we support updating from?
kernel26 still has replaces=('kernel24'), although I think updating from a system that still supported kernel24 will be impossible without major problems. I don't think there was ever a guideline on removing these, other than a vague "when it makes sense".
On 13/06/10 20:50, Thomas Bächler wrote:
Am 13.06.2010 12:43, schrieb Allan McRae:
Hi,
Do we have any guidelines on when to remove the provides/conflicts/replaces arrays from a PKGBUILD? In other words, what is the oldest system we support updating from?
kernel26 still has replaces=('kernel24'), although I think updating from a system that still supported kernel24 will be impossible without major problems.
I don't think there was ever a guideline on removing these, other than a vague "when it makes sense".
OK. I thought about this when looking at the coreutils PKGBUILD: provides=('mktemp') conflicts=('mktemp') replaces=('sh-utils' 'fileutils' 'textutils' 'mktemp') The mktemp replacement was done in early 2008 and the fileutils/textutils/mktemp would probably have been done in 2003. Clearly the replacement of packages from 2003 is unnecessary, but I am not sure about 2008 so I will leave those in at the moment. Allan
Am 13.06.2010 13:17, schrieb Allan McRae:
On 13/06/10 20:50, Thomas Bächler wrote:
Am 13.06.2010 12:43, schrieb Allan McRae:
Hi,
Do we have any guidelines on when to remove the provides/conflicts/replaces arrays from a PKGBUILD? In other words, what is the oldest system we support updating from?
kernel26 still has replaces=('kernel24'), although I think updating from a system that still supported kernel24 will be impossible without major problems.
I don't think there was ever a guideline on removing these, other than a vague "when it makes sense".
OK. I thought about this when looking at the coreutils PKGBUILD:
provides=('mktemp') conflicts=('mktemp') replaces=('sh-utils' 'fileutils' 'textutils' 'mktemp')
The mktemp replacement was done in early 2008 and the fileutils/textutils/mktemp would probably have been done in 2003.
Clearly the replacement of packages from 2003 is unnecessary, but I am not sure about 2008 so I will leave those in at the moment.
I'd say you can definitely get rid of the provides and conflicts. There is probably no package depending on mktemp anymore. If there is one, it should be considered a bug. I'd leave the replaces in for mktemp at least, a system from early 2008 might still be upgraded.
Am 13.06.2010 13:18, schrieb Thomas Bächler:
I'd leave the replaces in for mktemp at least, a system from early 2008 might still be upgraded.
I just tried to upgrade a system I hadn't touched since June 2007: http://npaste.de/XG/ The problem was this: debug: missing dependency 'sh' for package 'xz' which triggered bash installation. I created a dummy package called 'sh' with nothing in it: http://npaste.de/XI/ And now there is fun: # pacman -Syu pacman: /lib/libc.so.6: version `GLIBC_2.7' not found (required by /usr/lib/libfetch.so) pacman: /lib/libc.so.6: version `GLIBC_2.7' not found (required by /usr/lib/libcrypto.so.1.0.0) This system has glibc 2.6.1 installed. I am running this in a chroot right now. On a real machine, I could extract a new glibc manually and try to use that to upgrade the 'glibc' package properly. However, if I was on the machine itself, I would be running 2.6.22.6, making it impossible to use this glibc version.
participants (2)
-
Allan McRae
-
Thomas Bächler