[arch-general] Package coordination with archlinuxfr repo?
Guys, How are packages coordinated between core, extra, community and archlinuxfr? I ask because there seems to be a lag in some of the package on archlinuxfr. I understand that archlinuxfr isn't "official", but there still needs to be some coordination when major updates like gcc take place. Of interest specifically: :: Starting full system upgrade... warning: gcc-gcj: local (4.5.2-1) is newer than archlinuxfr (4.5.1-1) warning: pdftk: local (1.44-2) is newer than archlinuxfr (1.41-5) Once Arch bumped to gcc 4.5.2, gcc-gcj and pdftk had to be uninstalled and rebuilt from AUR. That's fine, but it just seems strange that archlinuxfr still has packages dependent on gcc 4.5.1. I know the gcc-gcj and pdftk PKGBUILDS are updated for 4.5.2 -- I did it. Do we need to send an email to the maintainer? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 12/01/11 13:22, David C. Rankin wrote:
How are packages coordinated between core, extra, community and archlinuxfr?
They are not. It is up to archlinux-fr to keep up.
On Tue, Jan 11, 2011 at 9:22 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
How are packages coordinated between core, extra, community and archlinuxfr? I ask because there seems to be a lag in some of the package on archlinuxfr. I understand that archlinuxfr isn't "official", but there still needs to be some coordination when major updates like gcc take place. Of interest specifically:
:: Starting full system upgrade... warning: gcc-gcj: local (4.5.2-1) is newer than archlinuxfr (4.5.1-1) warning: pdftk: local (1.44-2) is newer than archlinuxfr (1.41-5)
it looks like you have archlinuxfr set to a higher priority than [core]/etc? don't do that :-) you want it last, so you can get things it has that the official repos do not. now, if your using it to get newer/alternate versions of existing packages ... then you'll just sorta have to deal with it for the reason Allan stated. it shouldn't really matter though ... why did you have to uninstall anything? i've done this before IIRC; just let pacman whine about it, and let it go about it's business upgrading the system. C Anthony
On 01/11/2011 11:10 PM, C Anthony Risinger wrote:
... why did you have to uninstall anything? i've done this before IIRC; just let pacman whine about it, and let it go about it's business upgrading the system.
C Anthony
Thanks Allan, C Anthony, With gcc-gcj 4.5.1 installed, gcc 4.5.2 would not install due to the gcc-gcj gcc 4.5.1 depends. pdftk depended on gcc-gcj. So both gcc-gcj and pdftk had to be uninstalled before gcc 4.5.2 would install (without any forcing or ignoring dependencies) Both removed, then gcc 4.5.2 installed and then rebuilt both from AUR :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, Jan 12, 2011 at 9:35 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
With gcc-gcj 4.5.1 installed, gcc 4.5.2 would not install due to the gcc-gcj gcc 4.5.1 depends. pdftk depended on gcc-gcj. So both gcc-gcj and pdftk had to be uninstalled before gcc 4.5.2 would install (without any forcing or ignoring dependencies) Both removed, then gcc 4.5.2 installed and then rebuilt both from AUR :p
i see :-) I want new thoughts about what the meaning of a package is ... and how it can be better represented for derivation from it's integrals; source code and user state. the tarball has served us well for a long time, but ... in the now-time of cheap encryption, distributed clouds, parallel peers and ... C Anthony
On 01/12/2011 10:51 PM, C Anthony Risinger wrote:
I want new thoughts about what the meaning of a package is ... and how it can be better represented for derivation from it's integrals; source code and user state. the tarball has served us well for a long time, but ... in the now-time of cheap encryption, distributed clouds, parallel peers and ...
So you want to talk calculus do you? Perhaps the method of strained time and strained coordinates would would give a better approximation? Poincare-Linstedt maybe? Seriously, I've been very impressed with Arch packaging compared to rpm or deb. KISS has served Arch well. The only thoughts I've had on the issue were with the gzipped package directory format of the repository indexes, but I don't see anything wrong with it. It works as well as it would in a flat file format or in some record oriented db format. I'm sure there is a faster way to do it, but I haven't noticed any slowness with the current system. A package in any distro provides the necessary installables along with a way to check for conflicts and resolve dependencies. The current packages do that well. The only differences that I've seen with pacman vs. some of the others were in areas of handling or anticipating previously installed config or font files that cause rare install failures. But, I think the KISS vs. 'try to anticipate everything' argument ways in favor of not radically changing how pacman handles these issues -- unless there is just a wealth of unused resources laying around to experiment with. Great question. I'd also be interested in what other ideas there are about positive and realistic improvement can be made to the current system. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (3)
-
Allan McRae
-
C Anthony Risinger
-
David C. Rankin