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
