Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist
On Sun, Dec 14, 2008 at 12:40 AM, Dan McGee <dpmcgee@gmail.com> wrote:
This is a dual signoff. I have split the pacman mirrorlist into its own package because 1) Pacman releases are not all that common (because its perfect software, of course!) 2) Our packaged mirrorlist often lags waaay behind the actual one in SVN, because I find it a waste to rebuild pacman just for mirrorlist changes. This will prevent that.
I don't actually run pacman, so 2 signoffs per arch would be wonderful. In addition, PLEASE let me know if anything goes awry during a normal upgrade process. This could include mirrorlist not being written to pacsave, mirrorlist disappearing, etc.
May i ask why pacman requires pacman-mirrorlist and not the other way around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can not operate without pacman.. Greg
Le Sun, 14 Dec 2008 10:03:03 +0200, "Grigorios Bouzakis" <grbzks@gmail.com> a écrit :
May i ask why pacman requires pacman-mirrorlist and not the other way around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can not operate without pacman..
Agreed, but I think a lot of users would forget to install if it weren't a dep. of pacman. Maybe pacman should be renamed something like pacman-core and both of them added to a "pacman" group? Also, I don't like the fact that the new mirrorlist is installed in place of the user's. I think most people edit their mirrorlist, and they don't want to redo it every time. A .pacnew file would probably be a better idea. -- catwell
On Sun, Dec 14, 2008 at 06:01, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Sun, 14 Dec 2008 10:03:03 +0200, "Grigorios Bouzakis" <grbzks@gmail.com> a écrit :
May i ask why pacman requires pacman-mirrorlist and not the other way around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can not operate without pacman..
Agreed, but I think a lot of users would forget to install if it weren't a dep. of pacman. Maybe pacman should be renamed something like pacman-core and both of them added to a "pacman" group? I really dislike this idea a lot. I think it's fine either way with depends really. Having the mirrorlist depend on pacman may be more correct, but it would confuse some people, so it's a tossup IMO.
Pierre Chapuis schrieb:
Le Sun, 14 Dec 2008 10:03:03 +0200, "Grigorios Bouzakis" <grbzks@gmail.com> a écrit :
May i ask why pacman requires pacman-mirrorlist and not the other way around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can not operate without pacman..
Agreed, but I think a lot of users would forget to install if it weren't a dep. of pacman. Maybe pacman should be renamed something like pacman-core and both of them added to a "pacman" group?
i like the idea. what would be the disadvantages, Daenyth?
Also, I don't like the fact that the new mirrorlist is installed in place of the user's. I think most people edit their mirrorlist, and they don't want to redo it every time. A .pacnew file would probably be a better idea.
for the mirrorlist, i think an update script would suit best, but that may be kind of not arch-way. i run vimdiff every time there is a new mirrorlist, but actually you could do all that with a script, that adds new and deletes old servers, keeping the users' choices -> commented out mirrors. H.G.
On Sun, Dec 14, 2008 at 09:18, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote:
i like the idea. what would be the disadvantages, Daenyth? I just think it's very ugly "solution". IMO, the current behavior is fine. Keep it elegant.
On Sun, Dec 14, 2008 at 9:49 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Sun, Dec 14, 2008 at 09:18, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote:
i like the idea. what would be the disadvantages, Daenyth? I just think it's very ugly "solution". IMO, the current behavior is fine. Keep it elegant.
I agree... Dan made this split to make things easy. Renaming the package and adding a group or a metapackage is not easy and obvious. While pacman may run fine without a mirrorlist, the pacman shipped with ArchLinux does not, by default. The hard dep makes complete sense. I imagine Dan feels similar. Anyone is welcome to rebuild pacman via abs if they feel that the defaults we ship are inappropriate
On Sun, Dec 14, 2008 at 8:18 AM, Hubert Grzeskowiak <arch-general-ml@nemesis13.de> wrote:
for the mirrorlist, i think an update script would suit best, but that may be kind of not arch-way. i run vimdiff every time there is a new mirrorlist, but actually you could do all that with a script, that adds new and deletes old servers, keeping the users' choices -> commented out mirrors.
You could always make your own file and include that, or add preferred mirrors to pacman.conf. You have a lot of options here.
Works fine here on a x86_64 machine. :) Just one question: # pacman -Su warning: pacman: local (3.2.1-2) is newer than core (3.2.1-1) :: Starting full system upgrade... warning: pacman: local (3.2.1-2) is newer than core (3.2.1-1) local database is up to date Why is this warning message showing twice? -- Hugo
On Mon, Dec 15, 2008 at 4:36 PM, Hugo Doria <hugodoria@gmail.com> wrote:
Works fine here on a x86_64 machine. :)
Just one question:
# pacman -Su warning: pacman: local (3.2.1-2) is newer than core (3.2.1-1) :: Starting full system upgrade... warning: pacman: local (3.2.1-2) is newer than core (3.2.1-1) local database is up to date
Why is this warning message showing twice?
-- Hugo
The first one is special because of this : 17 # If upgrades are available for these packages they will be asked for first 18 SyncFirst = pacman Packages in syncfirst are checked before the actual upgrade, so this includes pacman. And at this moment, the first warning is made. Then for the full system upgrade, all your locally installed packages are checked, so that includes pacman again. Of course the code for checking the locally installed version against the repository version is always the same, it is just called twice for packages in SyncFirst, so eventual warnings are displayed twice.
participants (7)
-
Aaron Griffin
-
Daenyth Blank
-
Grigorios Bouzakis
-
Hubert Grzeskowiak
-
Hugo Doria
-
Pierre Chapuis
-
Xavier