[arch-dev-public] [signoff] pacman 3.3.0
Signoff for pacman/makepkg 3.3.0. Notable things: * once this goes in, we can officially start doing split packaging and build()/package() usage in our PKGBUILDs. * this is basically a signoff for libfetch too, and you can remove libdownload from your system. Allan (and others)- I added a carbon copy version of makepkg.conf to SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity check policy? -Dan
Dan McGee wrote:
Allan (and others)- I added a carbon copy version of makepkg.conf to SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity check policy?
Here go my recommendations: 1) Arch LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed There are very few problems with --as-needed these days and several other distros are using it to. You can always do an somthing like export LDFLAGS="" if it fails (much like is done when our CFLAGS cause issues. The -Wl,--hash-style=gnu will cause us not to have sysv hashes in our packages (we currently patch gcc to have both so building without makepkg will be unaffected). 2) Arch integrity check policy. This is the default checksum produced with "makepkg -g". Stick with md5sum or go to sha256? I don't care but md5sum has collisions so maybe sha256 is the way to go. Allan
Am Montag 03 August 2009 05:36:53 schrieb Allan McRae:
1) Arch LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed There are very few problems with --as-needed these days and several other distros are using it to. You can always do an somthing like export LDFLAGS="" if it fails (much like is done when our CFLAGS cause issues. The -Wl,--hash-style=gnu will cause us not to have sysv hashes in our packages (we currently patch gcc to have both so building without makepkg will be unaffected).
+1
2) Arch integrity check policy. This is the default checksum produced with "makepkg -g". Stick with md5sum or go to sha256? I don't care but md5sum has collisions so maybe sha256 is the way to go.
Afaik md5sum is good enough for download verification. But I don't really care as long as we could use both. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Mon, Aug 3, 2009 at 10:19, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 03 August 2009 05:36:53 schrieb Allan McRae:
1) Arch LDFLAGS: -Wl,--hash-style=gnu -Wl,--as-needed There are very few problems with --as-needed these days and several other distros are using it to. You can always do an somthing like export LDFLAGS="" if it fails (much like is done when our CFLAGS cause issues. The -Wl,--hash-style=gnu will cause us not to have sysv hashes in our packages (we currently patch gcc to have both so building without makepkg will be unaffected).
+1
2) Arch integrity check policy. This is the default checksum produced with "makepkg -g". Stick with md5sum or go to sha256? I don't care but md5sum has collisions so maybe sha256 is the way to go.
Afaik md5sum is good enough for download verification. But I don't really care as long as we could use both.
I think md5sum collisions are more security-related stuff, and for security we need signed packages anyway. When speaking about checking package integrity - md5sum does its jub fine. So I see no benefit in moving to sha256. -- Roman Kyrylych (Роман Кирилич)
Am Montag 03 August 2009 11:06:37 schrieb Roman Kyrylych:
2) Arch integrity check policy. This is the default checksum produced with "makepkg -g". Stick with md5sum or go to sha256? I don't care but md5sum has collisions so maybe sha256 is the way to go.
Afaik md5sum is good enough for download verification. But I don't really care as long as we could use both.
I think md5sum collisions are more security-related stuff, and for security we need signed packages anyway. When speaking about checking package integrity - md5sum does its jub fine. So I see no benefit in moving to sha256.
That's what I meant. Its very unlikely that you download a broken package due to networking problems which has the same md5sum and is also a valid tar.gz. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Sun, 2009-08-02 at 20:18 -0500, Dan McGee wrote:
Signoff for pacman/makepkg 3.3.0. Notable things:
* once this goes in, we can officially start doing split packaging and build()/package() usage in our PKGBUILDs. * this is basically a signoff for libfetch too, and you can remove libdownload from your system.
Allan (and others)- I added a carbon copy version of makepkg.conf to SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity check policy?
-Dan
Signoff 3.3.0-2 for both architectures. Builds fine, installs fine. I already made some split packages (mesa, libgsf).
Am Montag 03 August 2009 03:18:28 schrieb Dan McGee:
Signoff for pacman/makepkg 3.3.0. Notable things:
* once this goes in, we can officially start doing split packaging and build()/package() usage in our PKGBUILDs. * this is basically a signoff for libfetch too, and you can remove libdownload from your system.
Allan (and others)- I added a carbon copy version of makepkg.conf to SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity check policy?
-Dan
I did not have any problems so far. And if the last commits did not break makepkg htat should be fine, too. :) Signed-off for both arches. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Tue, Aug 4, 2009 at 6:31 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Montag 03 August 2009 03:18:28 schrieb Dan McGee:
Signoff for pacman/makepkg 3.3.0. Notable things:
* once this goes in, we can officially start doing split packaging and build()/package() usage in our PKGBUILDs. * this is basically a signoff for libfetch too, and you can remove libdownload from your system.
Allan (and others)- I added a carbon copy version of makepkg.conf to SVN. Do we want to establish (1) Arch LDFLAGS or (2) Arch integrity check policy?
-Dan
I did not have any problems so far. And if the last commits did not break makepkg htat should be fine, too. :)
OK, since this was more than just one package, I'll just state here what I'm about to do (especially for the ISO guys, pay attention): * move pacman and libfetch to [core] from [testing] * drop libdownload entirely, it is no longer needed by any package * move licenses to [core], mildly related as pacman 3.3 now handles symlink/dir conflicts -Dan
participants (5)
-
Allan McRae
-
Dan McGee
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych