Pacman

Welcome to the Pacman bug tracker. 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 reproducible test case whenever possible.
Tasklist

FS#25568 - support listing expanded directory names

Attached to Project: Pacman
Opened by Dieter Plaetinck (Dieter_be) - Sunday, 14 August 2011, 09:37 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 09 February 2018, 06:45 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version 3.5.3
Due in Version 5.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I would like a pacman option that outputs all expanded, defined repositories.

It's easier to explain with an example:
If you have this config:
[core]
/repo/$repo/$arch
[testing]
/somedir/$repo/$arch
[community]
Include = /etc/pacman.d/mirrorlist

I want something like:
$ pacman --listrepos
core /repo/core/i686
testing /somedir/testing/i686
community /etc/pacman.d/mirrorlist

Why? In AIF i track repositories in their unexpanded form (with variables, so that pacman can expand them correctly), but in AIF I also need to configure CacheDirs for pacman, in which these variables make no sense, so I want the expanded forms.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 09 February 2018, 06:45 GMT
Reason for closing:  Implemented
Additional comments about closing:  https://git.archlinux.org/pacman.git/com mit/?id=170bb80a1f8a020595738c7febdb15c6 8574ce29
Comment by Dan McGee (toofishes) - Monday, 15 August 2011, 02:22 GMT
Can you please be a bit more syntactically correct with your example? You are missing any "Server =" bits, and I'm not sure what you intend to do with the mix of Server and Include lines, nor what to do when multiple servers and/or includes are present for a [repo] section.

Wouldn't we also want to recursively expand the Include if we are going to expand the variables?

Finally, you're conflating servers with directories with repositories here- it seems like you are asking for a way to get expanded server URLs for all repositories- is that correct? And finally, I'm not following your CacheDirs logic, but I don't think that has much to do with the actual feature request here so no worries.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 15 August 2011, 07:42 GMT
Okay, I meant a config like this:
[core]
Server = /repo/$repo/$arch
[testing]
Server = /somedir/$repo/$arch
[community]
Include = /etc/pacman.d/mirrorlist

I know this is often not the recommended approach, but it is technically possible to combine local and remote repositories, and it can make sense (if the user knows what he's doing and for example created the local or remote repository himself)

There are no multiple servers and/or includes per [repo] section.

As for the CacheDirs: this is for archiso images: I need to know all actual directory names for all local repositories (like /repo/$repo/$arch), so they can be used as cachedirs (the package files are in there already, might as well use them as read only cache, with 1 extra cachedir for all files not found in local repositories). And it's cleaner to let pacman expand the $repo and $arch variables rather then trying to do it in AIF.

I didn't think about expanding the Includes at first but you're right that it would be more consistent.
Maybe an output format like this?:
core Server /repo/core/i686
testing Server /somedir/testing/i686
community Include /etc/pacman.d/mirrorlist http://mirrors.kernel.org/archlinux/community/os/i686 [,*more repository locations could go here, depending on what's uncommented in /etc/pacman.d/mirrrolist*]
Comment by Dan McGee (toofishes) - Friday, 19 August 2011, 16:14 GMT
I believe this fits well into Dave and I's eventual plan to have a config parser every pacman application can use. I can imagine a minimal libalpm-linked program in the future that spits out a machine consumable, fully-parsed config file.
Comment by Eli Schwartz (eschwartz) - Friday, 09 February 2018, 06:32 GMT

Loading...