You are not logged in.
I want to find out without fetching remote repo. How can I do that?
Offline
Offline
I suspect it's not about the official arch repos core, extra, multilib - where the definition already hints it:
core: stuff to boot the system
multilib: 32bit
extra: all other 64bit
so - unless it's a 32bit package or required to boot it must be from extra
but that's not what's asked here, is it?
Offline
core: stuff to boot the system
That's pretty much rubbish as an actual test. Are dash, groff, or links used to boot the system? How about nano and vi? Or sqlite and all of it's tools including sqlite-tcl? None of those are for booting the system but they're all in [core].
But for the original question of the thread: you can't. Pacman does not store the repo that a package came from in any local database or log file. But the local copy of the sync database will give the repo for any packages that were in the repos at the last sync - this could be a pretty reliable proxy for a range of use cases.
Last edited by Trilby (2024-07-30 19:11:55)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I want to find out without fetching remote repo. How can I do that?
I'll use gimp in this example.
pacman -Si gimp
The information from -Qi and -Si may at first glance appear the same, but there are differences and one is -Si does show the Repository.
-Qi shows information from the local database, or packages that are installed.
-Si shows information from the sync database, or the downloaded metadata from the mirrors.
This may not meet your needs, but if you want current information without updating your running system's sync database, you could run checkupdates and then "pacman -Si --dbpath=/tmp/checkup-db-$UID gimp".
Offline
cryptearth wrote:core: stuff to boot the system
That's pretty much rubbish as an actual test. Are dash, groff, or links used to boot the system? How about nano and vi? Or sqlite and all of it's tools including sqlite-tcl? None of those are for booting the system but they're all in [core]
actual my rather simple and rough description comes straight from the wiki: https://wiki.archlinux.org/title/Offici … ories#core
core contains packages for:
booting Arch Linux
connecting to the Internet
building packages
management and repair of supported file systems
the system setup process (e.g. openssh)
while I question why an install/rescue system requires ssh or why it auto-starts a ssh server which is useless unless one sets a root password
anyway ... I still don't think the actual question here really is "does a package belong to core, extra or multilib?", as this is kina trivial, but rather either additional added repos, the AUR or even specific git(hub) repos
Offline
How can I find out from which repo is the package?
expac
$ expac -S '%r' bash
core
$ expac -S '%r' python2
aur
Last edited by NuSkool (2024-07-30 23:48:22)
Offline
We should all wait for OP to specify anything at all, because that wasn't much to work with.
Offline
I meant without having access to the internet.
Offline
How can I find out from which repo is the package?
expac
$ expac -S '%r' bash core $ expac -S '%r' python2 aur
This one answered my question. I'll read about expac utility then.
Last edited by aljustiet (2024-08-01 06:56:18)
Offline
Without fetching the repo and without internet access? You can't. expac requires the remote repo.
Offline
Without fetching the repo and without internet access? You can't. expac requires the remote repo.
And even that wouldn't tell you where the package came from, only where the package could be obtained from at the date of the last sync.
Offline
Again, do you already have a local copy of the sync database? On any functioning arch system you would. And you can check that quite trivially:
pacman -Si $pkg | sed -n 's/^Repository *: //p'
This is dated information, and it's possible the package has moved since the last sync, but again - under a wide range of common usage conditions - this would give valid results.
Whether your usage conditions fit this, however, is unclear as you still have not actually clarified your goal. Don't tell us what your goal isn't just tell us what it is. What are you really trying to do?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Again, do you already have a local copy of the sync database? On any functioning arch system you would. And you can check that quite trivially:
pacman -Si $pkg | sed -n 's/^Repository *: //p'
This is dated information, and it's possible the package has moved since the last sync, but again - under a wide range of common usage conditions - this would give valid results.
Whether your usage conditions fit this, however, is unclear as you still have not actually clarified your goal. Don't tell us what your goal isn't just tell us what it is. What are you really trying to do?
I wanted to find out which repository the package is from, locally.
I don't care if the local database is up to date or not; I just want to find out how I can query it locally.
Last edited by aljustiet (2024-08-01 13:05:30)
Offline
I wanted to find out which repository the package is from, locally.
Yeah, we got that. By WHY? What package(s)? And under what conditions would this be needed / useful? Is this on a functioning arch system, or do you only have access to a *.pkg.tar.xz file? The answer depends on these details.
Does the command I just provided suffice? If not, why not?
Last edited by Trilby (2024-08-01 13:34:56)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
aljustiet wrote:I wanted to find out which repository the package is from, locally.
Yeah, we got that. By WHY? What package(s)? And under what conditions would this be needed / useful? Is this on a functioning arch system, or do you only have access to a *.pkg.tar.xz file? The answer depends on these details.
Does the command I just provided suffice? If not, why not?
I wanted to be able to do it locally without depending on the remote machine. Doing it locally is also faster than connecting to the remote machine. Additionally, I have electricity issues here, and it's unknown when it might go out. Therefore, I wanted to be able to do it independently.
Offline
So you just ignored most of my questions ... got it. I'm talking to a wall.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
So you just ignored most of my questions ... got it. I'm talking to a wall.
Yes it's functioning arch system.
The desire how can I do it, came when I wanted to find out from which repo is the glib2 package from, I `pacman -Qi`ed but it didn't return the repository where it is. Then I `pacman -Si`ed it, it returned, but then I wanted to be able to do it locally without using the -S option. My goal was, to make the shell alias where I enter the package name and it will return the repo, e.g: `fwr glib2`.
Last edited by aljustiet (2024-08-01 14:17:03)
Offline
So this entire thing is because you don't know what -S does
Offline
So this entire thing is because you don't know what -S does
I thought that every command with -S option fetches remote machines.
Offline
Only with -y
Offline
The `pacman -Si` command reads from the local sync databases under /var/lib/pacman/sync and does not fetch anything from a remote machine. However, for that to work, those sync databases must have previously been retrieved from a remote machine. On a regularly maintained arch system, this is not a concern as they are synced every update, and for typical repo packages like glib2 this should prove generally reliable. There are - however - a range of conditions in which this might give the "wrong" answer depending on exactly what information you needed which is why the context matters.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
The recent merger of extra and community might have been such an occasion.
Offline