[arch-dev-public] [signoff] pacman 4.0.0-2

[Pierre Schmitz]

Am 14.10.2011 14:43, schrieb Dan McGee:
> On Fri, Oct 14, 2011 at 12:45 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
>> Am 14.10.2011 07:34, schrieb Allan McRae:
>>> On 14/10/11 15:10, Pierre Schmitz wrote:
>>>> I just noticed a somehow unexpected behavior: When I run "pacman -S
>>>> devtools" (still had namcap version 3.1) pacman wanted to install these
>>>> pacakges:
>>>>   namcap-3.1-1  pacman-3.5.4-4  pyalpm-0.4.3-1  subversion-1.6.17-6
>>>> devtools-0.9.27-1
>>>
>>> I am majorly confused as why a "pacman -S devtools" would pull
>>> namcap/pyalpm/pacman in if you already had namcap installed and there
>>> are no versioned deps for devtools.  I assume you had subversion
>>> installed too...
>>
>> no, here is how I did it: When noticing that pacman wont upgrade due to
>> pylibalpm being incompatible I removed it with Rcsn which also removed
>> devtools. The next day I tried pacman -Syu and pacamn -.S devtools which
>> results in the behavior described.
>>
>> Also, even after syncing my repo I still had trouble updating. Note
>> that I had pacman 3.5 and the old pyalpm at this time. As -Syu then
>> wanted to update pacman first to 4.0 but failed as it did not update
>> libalpm at the same time. I guess this is a different issue with
>> SyncFirst. It only updates pacman and its deps but no those packages
>> that depend on a specific pacman version and therefor fails. I am not
>> sure if we can solve this issue in a sane way though. At least we should
>> add this to the announcement that one needs to temporary remove pyalpm
>> before updating pacman and reinstall it afterwards.
> Or treat this like any other TODO list and have all the packages ready
> to go in [testing], just like it is now.

I see my text was probably hard to read, but it was not about some
packages not being updated for pacman 4.0 yet but a possible bug (or
two) in pacman itself.

-- 
Pierre Schmitz, https://users.archlinux.de/~pierre