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

[Oon-Ee Ng]

On Fri, Oct 14, 2011 at 3:42 AM, Rémy Oudompheng <remy at archlinux.org> wrote:
> On 2011/10/13 Pierre Schmitz <pierre at archlinux.de> wrote:
>> Am 13.10.2011 20:22, schrieb Dan McGee:
>>> The most anticipated release EVER has landed in [testing]. Do I expect
>>> it to make it out before we need a 4.0.1? Not really. :)
>>>
>>> Upstream NEWS/changes:
>>> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
>>> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
>>> been actually released.
>>>
>>> Questions? Concerns? Comments?
>>
>> Big thanks to everybody involved with this great release. About that
>> issue I am not supposed to talk here I'll send a mail tomorrow. :-)
>>
>> Good thing you moved this into testing so there are no excuses not to
>> test the new pacman. Do you know if porting pyalpm will be easy or is
>> already done? Would be beter to have this sorted out before moving 4.0
>> to core. (pyalpm is needed by namcap) I also need to have a look at this
>> code:
>> https://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux
>> But should be easy enough to port if even necessary.
>
> I've followed pacman API changes in pyalpm's trunk all along and will
> do the appropriate release asap.
>
> Rémy.
>

Something to note, even though pyalpm is updated to support pacman 4.0
some user intervention would be required, since they'd get this error
on upgrade if they answer Y to the question below:-
:: The following packages should be upgraded first :
    pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n]

resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: pyalpm: requires pacman<3.6

Don't think there's a way to deal with that though, either the user
answers 'n' or upgrades pacman with -d? Both are
manual-intervention-required =)