On 13/06/10 23:03, Emmanuel Benisty wrote:
On Sun, Jun 13, 2010 at 6:18 PM, Thomas Bächler<thomas@xxxxxxxxxxxxx> wrote:
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.
Just FTR:
$ spacman -Su
Password:
:: Starting full system upgrade...
warning: dmenu: local (4.1.1-1) is newer than extra (4.0-2)
warning: firefox: local (3.7a6-1) is newer than extra (3.6.3-1)
warning: procinfo-ng: local (2.0.304-2) is newer than core (2.0.304-1)
warning: schedtool: local (1.3.0-1) is newer than extra (1.2.9-2)
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: quilt: requires mktemp
Fixed. This appears to be the only package that still had a mktemp dep.
Allan
