[pacman-dev] [PATCH] Remove pacman.static build from build files

newer
[pacman-dev] [PATCH] Use LC_ALL=C...

older
[pacman-dev] static libraries not...

Dan McGee

16 Jul 2008 16 Jul '08

3:15 a.m.

This presents plenty of problems on OSes besides Linux, and even on Linux when the libtool file for libarchive isn't present. The static build isn't all that useful anyway as missing something such as glibc will still leave you unable to run the pacman.static binary. Remove it from the formal build process. Signed-off-by: Dan McGee --- configure.ac | 16 ---------------- src/pacman/.gitignore | 2 -- src/pacman/Makefile.am | 7 ------- 3 files changed, 0 insertions(+), 25 deletions(-) diff --git a/configure.ac b/configure.ac index ab5a374..b4b6a56 100644 --- a/configure.ac +++ b/configure.ac @@ -119,11 +119,6 @@ AC_ARG_ENABLE(git-version, [enable use of git version in version string if available]), [wantgitver=$enableval], [wantgitver=no]) -# Help line for pacman.static -AC_ARG_ENABLE(pacman-static, - AS_HELP_STRING([--disable-pacman-static], [do not build static version of pacman]), - [pacmanstatic=$enableval], [pacmanstatic=yes]) - # Checks for programs. AC_PROG_AWK AC_PROG_CC_C99 @@ -324,16 +319,6 @@ else fi AM_CONDITIONAL(USE_GIT_VERSION, test "x$usegitver" = "xyes") -# Enable or disable inclusion of pacman.static -AC_MSG_CHECKING(whether to build pacman.static) -if test "x$pacmanstatic" = "xyes" ; then - AC_MSG_RESULT(yes) - AC_DEFINE([INCLUDE_PACMAN_STATIC], , [Build pacman.static]) -else - AC_MSG_RESULT(no) -fi -AM_CONDITIONAL(INCLUDE_PACMAN_STATIC, test "x$pacmanstatic" = "xyes") - # Set root directory AC_SUBST(ROOTDIR) # Set package file extension @@ -398,7 +383,6 @@ ${PACKAGE_NAME}: Doxygen support : ${usedoxygen} Asciidoc support : ${useasciidoc} debug support : ${debug} - build pacman.static : ${pacmanstatic} " # vim:set ts=2 sw=2 noet: diff --git a/src/pacman/.gitignore b/src/pacman/.gitignore index c47851c..6a358aa 100644 --- a/src/pacman/.gitignore +++ b/src/pacman/.gitignore @@ -2,5 +2,3 @@ .libs pacman pacman.exe -pacman.static -pacman.static.exe diff --git a/src/pacman/Makefile.am b/src/pacman/Makefile.am index e5f8cb3..220ee9c 100644 --- a/src/pacman/Makefile.am +++ b/src/pacman/Makefile.am @@ -6,10 +6,6 @@ logfile = ${localstatedir}/log/pacman.log bin_PROGRAMS = pacman -if INCLUDE_PACMAN_STATIC -bin_PROGRAMS += pacman.static -endif - DEFS = -DLOCALEDIR=\"@localedir@\" \ -DCONFFILE=\"$(conffile)\" \ -DROOTDIR=\"$(ROOTDIR)\" \ @@ -40,7 +36,4 @@ pacman_SOURCES = \ LDADD = $(LTLIBINTL) $(top_builddir)/lib/libalpm/.libs/libalpm.la -pacman_static_SOURCES = $(pacman_SOURCES) -pacman_static_LDFLAGS = $(LDFLAGS) -all-static - # vim:set ts=2 sw=2 noet: -- 1.5.6.2

Show replies by date

Dan McGee

16 Jul 16 Jul

3:15 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :) Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p') elif [ ! -z ${_bzrtrunk} ] && [ ! -z ${_bzrmod} ] ; then [ $(type -p bzr) ] || return 0 msg "$(gettext "Determining latest bzr revision...")" -- 1.5.6.2

Dan McGee

3:21 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...

Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p') I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

...

elif [ ! -z ${_bzrtrunk} ] && [ ! -z ${_bzrmod} ] ; then [ $(type -p bzr) ] || return 0 msg "$(gettext "Determining latest bzr revision...")" -- 1.5.6.2

Allan McRae

4:25 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Dan McGee wrote:

...

On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...
Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p')

I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good. Allan

Xavier

9:45 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Allan McRae wrote:

...

Dan McGee wrote:

...
On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...
Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p')

I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good.

Here is a filtered output of git grep LC_ALL : contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so scripts/makepkg.sh.in: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO So maybe we could change the first two for a better consistency?

Dan McGee

2:22 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Wed, Jul 16, 2008 at 1:45 AM, Xavier wrote:

...

Allan McRae wrote:

...
Dan McGee wrote:

...
On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...
Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p')

I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good.

Here is a filtered output of git grep LC_ALL :

contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO This one should probably change to match makepkg anyway...

...

doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so I don't think this one is as big of deal, do you?

...

scripts/makepkg.sh.in: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO

So maybe we could change the first two for a better consistency?

Allan McRae

2:33 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Dan McGee wrote:

...

On Wed, Jul 16, 2008 at 1:45 AM, Xavier wrote:

...
Allan McRae wrote:

...
Dan McGee wrote:

...
On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...
Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p')

I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good.

Here is a filtered output of git grep LC_ALL :

contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO

This one should probably change to match makepkg anyway...

...
doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so

I don't think this one is as big of deal, do you?

...
scripts/makepkg.sh.in: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO

So maybe we could change the first two for a better consistency?

Hmmm, after some google searching. LC_ALL appears to override any other LC_* variable and the LANG variable. So "LANG=" here is redundant. I couldn't find whether there is a difference between "LC_ALL=C" and "LC_ALL=" but I am suspecting there isn't... Allan

Dan McGee

2:39 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Wed, Jul 16, 2008 at 6:33 AM, Allan McRae wrote:

...

Dan McGee wrote:

...
On Wed, Jul 16, 2008 at 1:45 AM, Xavier wrote:

...
Allan McRae wrote:

...
Dan McGee wrote:

...
On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

...
Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to get the current revision number, which is much quicker for large Subversion repositories. Eventually git will rule the world. :)

Signed-off-by: Dan McGee --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b810d60..2ab2aef 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1017,7 +1017,7 @@ devel_check() { elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p')

I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good.

Here is a filtered output of git grep LC_ALL :

contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO

This one should probably change to match makepkg anyway...

...
doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so

I don't think this one is as big of deal, do you?

...
scripts/makepkg.sh.in: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO

So maybe we could change the first two for a better consistency?

Hmmm, after some google searching. LC_ALL appears to override any other LC_* variable and the LANG variable. So "LANG=" here is redundant. I couldn't find whether there is a difference between "LC_ALL=C" and "LC_ALL=" but I am suspecting there isn't...

Hmm, ok. That does make sense. Whatever works and is simplest is fine with me, and it would be ideal for it to work on platforms besides Linux as well. -Dan

Allan McRae

2:47 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Dan McGee wrote:

...

On Wed, Jul 16, 2008 at 6:33 AM, Allan McRae wrote:

...
Dan McGee wrote:

...
On Wed, Jul 16, 2008 at 1:45 AM, Xavier wrote:

...
Allan McRae wrote:

...
Dan McGee wrote:

...
On Tue, Jul 15, 2008 at 7:15 PM, Dan McGee wrote:

> Using the suggestion from FS#10905, use 'svn info' rather than 'svn log' to > get the current revision number, which is much quicker for large Subversion > repositories. Eventually git will rule the world. :) > > Signed-off-by: Dan McGee > --- > scripts/makepkg.sh.in | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in > index b810d60..2ab2aef 100644 > --- a/scripts/makepkg.sh.in > +++ b/scripts/makepkg.sh.in > @@ -1017,7 +1017,7 @@ devel_check() { > elif [ ! -z ${_svntrunk} ] && [ ! -z ${_svnmod} ] ; then > [ $(type -p svn) ] || return 0 > msg "$(gettext "Determining latest svn revision...")" > - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r$[0-9]*$ .*$/\1/p') > + newpkgver=$(LC_ALL= LANG= svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p') > > > I settled on this after I saw a similar use case elsewhere in makepkg: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO I think it makes sense. Let me know if anyone has better ideas.

From memory, that is the cleaner way to unset the locales so it is all good.

Here is a filtered output of git grep LC_ALL :

contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO

This one should probably change to match makepkg anyway...

...
doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so

I don't think this one is as big of deal, do you?

...
scripts/makepkg.sh.in: echo "# $(LC_ALL= LANG= date -u)" >>.PKGINFO

So maybe we could change the first two for a better consistency?

Hmmm, after some google searching. LC_ALL appears to override any other LC_* variable and the LANG variable. So "LANG=" here is redundant. I couldn't find whether there is a difference between "LC_ALL=C" and "LC_ALL=" but I am suspecting there isn't...

Hmm, ok. That does make sense.

Whatever works and is simplest is fine with me, and it would be ideal for it to work on platforms besides Linux as well.

More google searching on this and requiring to correct my previous assertions... "LC_ALL=C" is equivalent to "LC_ALL=POSIX". Just using "LC_ALL=" does require "LANG=" as if LC_ALL is unset it then looks at the LANG variable. So the following all are equivalent (I think...): LC_ALL= LANG= LC_ALL=C <- my vote LC_ALL=POSIX Allan

Xavier

3:14 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Wed, Jul 16, 2008 at 1:47 PM, Allan McRae wrote:

...

More google searching on this and requiring to correct my previous assertions... "LC_ALL=C" is equivalent to "LC_ALL=POSIX". Just using "LC_ALL=" does require "LANG=" as if LC_ALL is unset it then looks at the LANG variable.

So the following all are equivalent (I think...): LC_ALL= LANG= LC_ALL=C <- my vote LC_ALL=POSIX

Also, LC_ALL= LANG= does not seem to work if LC_MESSAGES is set. So I guess you have to use LC_ALL= LANG= LC_MESSAGES= I would also prefer to just use LC_ALL=C everywhere if that is possible.

Dan McGee

18 Jul 18 Jul

4:15 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Wed, Jul 16, 2008 at 7:14 AM, Xavier wrote:

...

On Wed, Jul 16, 2008 at 1:47 PM, Allan McRae wrote:

...
More google searching on this and requiring to correct my previous assertions... "LC_ALL=C" is equivalent to "LC_ALL=POSIX". Just using "LC_ALL=" does require "LANG=" as if LC_ALL is unset it then looks at the LANG variable.

So the following all are equivalent (I think...): LC_ALL= LANG= LC_ALL=C <- my vote LC_ALL=POSIX

Also, LC_ALL= LANG= does not seem to work if LC_MESSAGES is set. So I guess you have to use LC_ALL= LANG= LC_MESSAGES=

I would also prefer to just use LC_ALL=C everywhere if that is possible.

Patches coming for this? Or what did we decide on? -Dan

Allan McRae

6:40 a.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

Dan McGee wrote:

...

On Wed, Jul 16, 2008 at 7:14 AM, Xavier wrote:

...
On Wed, Jul 16, 2008 at 1:47 PM, Allan McRae wrote:

...
More google searching on this and requiring to correct my previous assertions... "LC_ALL=C" is equivalent to "LC_ALL=POSIX". Just using "LC_ALL=" does require "LANG=" as if LC_ALL is unset it then looks at the LANG variable.

So the following all are equivalent (I think...): LC_ALL= LANG= LC_ALL=C <- my vote LC_ALL=POSIX

Also, LC_ALL= LANG= does not seem to work if LC_MESSAGES is set. So I guess you have to use LC_ALL= LANG= LC_MESSAGES=

I would also prefer to just use LC_ALL=C everywhere if that is possible.

Patches coming for this? Or what did we decide on?

Patch on its way that uses LC_ALL=C everywhere. Allan

Xavier

16 Jul 16 Jul

2:34 p.m.

New subject: [pacman-dev] [PATCH] makepkg: speed up svn revision check for large repositories

On Wed, Jul 16, 2008 at 1:22 PM, Dan McGee wrote:

...

...
Here is a filtered output of git grep LC_ALL :

contrib/bacman:echo "# $(LC_ALL=C date)" >> .PKGINFO

This one should probably change to match makepkg anyway...

...
doc/makepkg.8.txt:seeking help or for other purposes, you may wish to run "`LC_ALL=C makepkg`" so I don't think this one is as big of deal, do you?

Well it would be easier to have the same way everywhere, but if LANG= LC_ALL= is supposed to be safer or more portable or whatever, and LC_ALL=C is easier to type, then ok.

Allan McRae

4:23 a.m.

Dan McGee wrote:

...

This presents plenty of problems on OSes besides Linux, and even on Linux when the libtool file for libarchive isn't present. The static build isn't all that useful anyway as missing something such as glibc will still leave you unable to run the pacman.static binary. Remove it from the formal build process.

I didn't realize that is was not very static. But is this not useful for people who want to try and upgrade their really old systems? I suppose if they can't get pacman going in the first place then they will be reasonably screwed with the rest of the upgrade.

Dan McGee

4:32 a.m.

On Tue, Jul 15, 2008 at 8:23 PM, Allan McRae wrote:

...

Dan McGee wrote:

...
This presents plenty of problems on OSes besides Linux, and even on Linux when the libtool file for libarchive isn't present. The static build isn't all that useful anyway as missing something such as glibc will still leave you unable to run the pacman.static binary. Remove it from the formal build process.

I didn't realize that is was not very static. But is this not useful for people who want to try and upgrade their really old systems? I suppose if they can't get pacman going in the first place then they will be reasonably screwed with the rest of the upgrade.

Yeah, I think it has always been one of those "I hope it works" type things. In any case, I think this is more appropriate for the pacman PKGBUILD if we truely want a static build, rather than in the pacman buildchain. If you really want to test the "screwing up" stuff, boot up Simo's live CD installer and do a pacman -R glibc, and see how functional the system is. You'll note that pacman.static is pretty bunk at that point. -Dan

5782

Age (days ago)

5784

Last active (days ago)

List overview

Download

14 comments

4 participants

participants (4)

Allan McRae
Dan McGee
Dan McGee
Xavier