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. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

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? I'm telling you as little as possible about this release and how to make things work to put more people in the "standard user who doesn't follow development like a hawk" shoes.

This thread is for the *package in testing only*. We have more work to do from a distro policy standpoint on signing; please do not discuss that here but in another thread.

-Dan

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 The thing to notice here is that it didn't warn that pylibalpm requires pacman 3.5 and that pacman did silently downgrade itself without any further notice. So in addition to the unexpected downgrade itselfthe SyncFirst option has no effect in this case? -- Pierre Schmitz, https://users.archlinux.de/~pierre

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. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

Am 14.10.2011 14:43, schrieb Dan McGee:

On Fri, Oct 14, 2011 at 12:45 AM, Pierre Schmitz 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