Welcome to the Pacman bug collection. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproduceable test case whenever possible.
Tasklist

FS#6812 - pacman -Syi ignores the -y

Attached to Project: Pacman
Opened by Thomas Bächler (brain0) - Wednesday, 04 April 2007, 15:50 GMT-5
Last edited by Dan McGee (toofishes) - Tuesday, 06 November 2007, 00:49 GMT-5
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.0
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

With pacman 2, when I ran pacman -Syi, it would first refresh the database and the perform the -i. With pacman 3, it only does the -i, ignoring the -y. You should also check the other -S operations, all of them should be performed after the -y if it is on the commandline.
This task depends upon

View Dependency Graph

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Tuesday, 06 November 2007, 00:49 GMT-5
Reason for closing:  Fixed
Additional comments about closing:  Tested and confirmed working in current pacman-git devel release.
Comment by Dan McGee (toofishes) - Monday, 16 April 2007, 21:45 GMT-5
Permissions checking in the codebase is currently not the cleanest. This fix would be quite extreme for pacman 3.0.1 wrt testing any regressions, so I don't want to make it there. We really need an overhaul of permissions stuff before we can fix this.
Comment by Xavier (shining) - Sunday, 29 July 2007, 14:05 GMT-5
What's the status of this?
Permissions checking isn't easy in general, but in relation to the current bug report, is there really a big problem ?
If -y is specified, then root access is needed, and that check should be enough.
And then maybe just moving the -y part at the top of the pacman_sync function.
Comment by Aaron Griffin (phrakture) - Thursday, 27 September 2007, 22:47 GMT-5
  • Field changed: Status (Assigned → Requires testing)
Committed changes in my working branch to all -y to function with -i, -g, -l, and -s options.
e.g. -Syl -Sys, etc etc
Comment by Xavier (shining) - Friday, 28 September 2007, 09:20 GMT-5
Hmm, I see, it's more complicated than I thought.
I'm not really satisfied by this solution of calling needs_transaction() twice.
But I've yet to come up with a better solution.

Also, note that there are 2 problems with the cleanup part now :
706 cleanup:
707 |_if(data) {
708 |_|_alpm_list_free(data);
709 |_}
710 |_if(alpm_trans_release() == -1) {
711 |_|_fprintf(stderr, _("error: failed to release transaction (%s)\n"),
712 |_|_ alpm_strerrorlast());
713 |_|_retval = 1;
714 |_}

For the data check to work correctly, I had to move its declaration at top of pacman_sync function, and initialize it to NULL.
Otherwise, pacman segfaults on _alpm_list_free(data);.
Just try running : sudo pacman -Sys foo

After that, there is still a problem with the second part, when doing for example : pacman -Ss foo
In this case, pacman doesn't initialize a transaction (just like before), but it'll now try to release it, and fail.
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 11:49 GMT-5
needs_transaction() isn't an expensive function. In fact, it's a handful of bitwise operations and probably faster than function call overhead.

Calling it twice isn't a bad thing at all, and that was actually why i broke it out, because in cases like this the _only_ thing we can do is check this, or keep track of it in a variable.

There isn't much else we can do, we need to have knowledge of whether we need a transaction or not with the current state of things - in the long run, transactions shouldn't be managed on the front-end, but that's a LONG time from now.
Comment by Xavier (shining) - Friday, 28 September 2007, 11:53 GMT-5
Another problem with this code :
418 if(needs_transaction() &&
419 alpm_trans_init(PM_TRANS_TYPE_SYNC, config->flags, cb_trans_evt,

If pacman is run in a chroot (eg like pactest does), being root is not needed, it can be run as user.
So needs_transaction return false (even though a transaction is in fact needed), and the transaction is not initialized.

Just look at the number of pactests failing in make check.
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 11:55 GMT-5
But needs_transaction doesn't check the uid at all.
Comment by Xavier (shining) - Friday, 28 September 2007, 13:01 GMT-5
But it does this :
55 || (strcmp(alpm_option_get_root(), "/") != 0)) {
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 13:07 GMT-5
Ah, ok, that's not a check for the root _user_, that's a check for the root _path_.

And I see what you mean. I will fix that tonight
Comment by Xavier (shining) - Saturday, 29 September 2007, 06:57 GMT-5
For this last problem, I just moved the root path check out of needs_transaction, and put it directly in pacman.c . I think this part is alright.

For the other problems, I thought about doing the transaction first, in a new sync trans function, which will init and release a transaction.
And then doing the commands like -Ss / -Sl / -Sg / -Si.

The problem is that for commands like -Sys / -Syl / etc, only the refresh part of the transaction should be done.
So I had to introduce an ugly sync_only hack.

Anyway, maybe this patch can give you some ideas.. But if you need more time to understand the crap I did than doing what you had in mind, just ignore it :)
Comment by Aaron Griffin (phrakture) - Tuesday, 02 October 2007, 14:59 GMT-5
Whoops, sorry, let me tag this one to do tonight.... /me runs in circles
Comment by Aaron Griffin (phrakture) - Wednesday, 03 October 2007, 22:11 GMT-5
Fixed the borken-ness, courtesy of the patch above.

http://code.phraktured.net/?p=pacman.git;a=shortlog;h=working

Loading...