Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#8540 - Config file loaded with defaults - pacman.conf.default

Attached to Project: Pacman
Opened by Travis Willard (Cerebral) - Wednesday, 07 November 2007, 00:17 GMT
Last edited by Dan McGee (toofishes) - Saturday, 06 March 2010, 14:43 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Neat idea I recently sent to Aaron - he told me to make an FS report for it, so here we go:

----------------
Oh! Here's a thought off the top of my head. pacman.conf.default.
Have that pre-loaded with default settings for all repos (core, extra,
etc...). This file we could update with each pacman package if we
needed to, pushing new repos to users and such.

Then, pacman.conf could have, as its last line,
Include=pacman.conf.default

That way we have a config file that's controlled by us - we can add new
repos, change repo names, etc... while still giving users the ability
to tweak the defaults we give.

Anyway, just a sudden spurious idea that came to mind
----------------
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 06 March 2010, 14:43 GMT
Reason for closing:  Won't implement
Additional comments about closing:  For now this just doesn't seem necessary nor can it cover the bases where a user wants to intersperse their repos with ours.
Comment by Aaron Griffin (phrakture) - Wednesday, 07 November 2007, 00:23 GMT
Jason had a good idea. We make a script that _somehow_ generates this file, put this entry commented out, with some suggested cron job or something like that... then we can use it for "lightweight repos" in the future - that is, independent repos for things like db rebuilds, xorg releases, etc etc
Comment by Dan McGee (toofishes) - Wednesday, 07 November 2007, 01:34 GMT
If we ever do this, we need some way of cleaning out old repos from people's /var/lib/pacman/sync dir, and more failure-resistant methods in pacman (currently, if you add a repo but haven't synced from it yet, you get all sorts of issues when you try to do any other operation).
Comment by Roman Kyrylych (Romashka) - Thursday, 08 November 2007, 13:05 GMT
This will work for testing repos created on demand, so user will be able to do -S python26/python without the need to update pacman.conf

This won't work with -Syu onyl if user has Unstable uncommented in pacman.conf and there's python3-3.0beta5 package here, and python-2.6 package in python26 repo - because Unstable will take precedence first.
If we'll rename Core or Extra repos - same things will happen.

But, this is still usefull - the ability of easy addition of testing-on-demand repos is worth it IMO.
Comment by Roman Kyrylych (Romashka) - Thursday, 08 November 2007, 13:09 GMT
I've made a mistake in previous comment about Unstable taking precedence - this will work, of course (because user will install with -S python26/python),
but will fail with non-versioned depends, which will be pulled from any repo in pacman.conf above that Include.
Comment by Allan McRae (Allan) - Saturday, 06 March 2010, 07:34 GMT
So, this is really not a pacman bug but a "pacman package" feature request given pacman can already handle this.

Anyway.... everybody seems to manage to add their own repos to pacman.conf (kdemod, gnome-unstable etc). We ship an Arch specific pacman.conf with the pacman package (as should any other distro using pacman) so shipping an updated pacman.conf is as simple as shipping an updated pacman. That gets synced first on update anyway. Finally, in Arch this would make it really difficult to add a repo (e.g.) between [extra] and [community].

So can we close this?

Loading...