FS#15561 - Upgrade only packages from the specified repository

Attached to Project: Pacman
Opened by Vladimir Mitrovic (vl4dimir) - Saturday, 18 July 2009, 13:54 GMT
Task Type Feature Request
Category General
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 17
Private No

Details

Summary and Info:

It would be cool if pacman was able to update only packages that come from a certain repository. It could be implemented as a suboption for the -Su action, so for example one can do 'pacman -Sur core', which would update only packages that come from the core repository.
This task depends upon

Comment by Gavin Bisesi (Daenyth) - Sunday, 13 September 2009, 23:37 GMT
You can do a type of workaround by doing pacman -S $(comm -1 -2 <(pacman -Sql $REPO) <(pacman -Qq[u]))
Comment by Laszlo Papp (djszapi) - Wednesday, 16 September 2009, 22:48 GMT
I think it would be nice. There is a similar selection on gentoo, emerge -DuN system which is similar like pacman -Sur core would be.
Comment by Allan McRae (Allan) - Wednesday, 16 September 2009, 23:54 GMT
From Arch's point of view, that can only lead to severe pain. But may be on a stable distro system where you only want update fro the [security] repo? or something... I'm not really seeing the point...
Comment by Dan McGee (toofishes) - Wednesday, 16 September 2009, 23:55 GMT
So we just made pacman able to accept targets with repo names everywhere. We also made -Syu able to take additional targets to include in the same transaction. If we hadn't done this, I would suggest a command like "pacman -Syu core/*" could be used, but hmm...
Comment by Laszlo Papp (djszapi) - Thursday, 17 September 2009, 04:24 GMT
It can be useful e.g. when I'd like to make a livecd. I need for updating only the core packages, and I needn't to update the whole system.

But it can cause problem with -Sur community, e.g. if the dependency is in the other repository, like extra or core, so maybe it would give an error or to allow it for dependencies to install from other repository.

pacman -Syu core/* seems good for me too.
Comment by Krisztian Ember (emberk) - Thursday, 17 September 2009, 10:54 GMT
I agree with Laszlo Papp
Comment by Xavier (shining) - Thursday, 17 September 2009, 11:09 GMT
why did you request a task closure then ?

And I am not sure you understood Dan's message, but it's not very clear.
"If we hadn't done this, I would suggest a command like "pacman -Syu core/*" could be used"

So since we did all this stuff, we cannot use "pacman -Syu core/*", right ?

If we allowed regex to be used in -S operation, it would make much more sense to match with packages from sync repo and not from local repo.
I mean, if you do pacman -S gstreamer* , you don't care about your locally installed packages, you want to install all gstreamer packages in sync repo.

So "pacman -Syu core/*" would upgrade/install all packages from core, which is different from what we wanted here.
Comment by David C. Rankin (drankinatty) - Saturday, 01 March 2014, 02:40 GMT
I would vote that updating individual repos only be allowed for non-arch repos. Or have all the arch repos update as a subgroup to prevent partial-update issues. It would be really helpful if a --repo option was added to -S so that a non-arch repo index or packages could be updated with

pacman -Sy --repo somerepo
Then an internal test something like
test3rdparty()
if [[ "$1" != core ]]&&[[ "$1" != community ]]&&[[ "$1" != extra ]]; then
OK update "$1"
else
No - core, community, extra must be updated together.
fi

same would apply to 'pacman -Su --repo somerepo'
Comment by Allan McRae (Allan) - Saturday, 01 March 2014, 02:47 GMT
pacman is not Arch specific and will never include Arch specific checks. This is either a feature for all repos or none.
Comment by Sebastian Stammler (epinephrine) - Monday, 13 February 2017, 12:47 GMT
You could add an option to pacman.conf named NativeRepos or DistRepos that lists the native repositories for this distro. E.g., in Arch that would be
NativeRepos = core extra community

Then you could add options to include or exclude only native or foreign repos and define special behaviour.

Loading...