Re: [arch-general] [arch-dev-public] [PATCH] Do not refer to $startdir/{src, pkg} in PKGBUILDs
On Tue, 2010-06-08 at 18:32 +0200, Pierre Schmitz wrote:
On Tue, 08 Jun 2010 17:43:47 +1000, Allan McRae <allan@archlinux.org> wrote:
$startdir will not be removed. The error printed for $startdir usage was always there so I did not change that. For install files, once 3.4 is released, you can put them in the source array without any issues and
then adjust them in $srcdir.
This patch was mainly to check for $startdir/pkg which will not be the same as $pkgdir from 3.5 onwards (i.e. two releases away). This is already true for split packages, but will become true for unsplit ones too. A lot of packages are affected but we have been telling people not to use $startdir/pkg for more that a year, maybe even two years...
No problem then. Maybe we could "sed" all $startdir/{pkg,src} usage in trunk for the remaining packages. This way startdir will be gone sooner or later.
Is this same advise applicable to AUR PKGBUILDs? If I read it correctly, $startdir/pkg is wrong, $pkgdir is correct, and $startdir is correct.
On 09/06/10 09:22, Ng Oon-Ee wrote:
On Tue, 2010-06-08 at 18:32 +0200, Pierre Schmitz wrote:
On Tue, 08 Jun 2010 17:43:47 +1000, Allan McRae<allan@archlinux.org> wrote:
$startdir will not be removed. The error printed for $startdir usage was always there so I did not change that. For install files, once 3.4 is released, you can put them in the source array without any issues and
then adjust them in $srcdir.
This patch was mainly to check for $startdir/pkg which will not be the same as $pkgdir from 3.5 onwards (i.e. two releases away). This is already true for split packages, but will become true for unsplit ones too. A lot of packages are affected but we have been telling people not to use $startdir/pkg for more that a year, maybe even two years...
No problem then. Maybe we could "sed" all $startdir/{pkg,src} usage in trunk for the remaining packages. This way startdir will be gone sooner or later.
Is this same advise applicable to AUR PKGBUILDs? If I read it correctly, $startdir/pkg is wrong, $pkgdir is correct, and $startdir is correct.
$pkgdir and $srcdir should always be used rather than $startdir/pkg and $startdir/src respectively as these are not guaranteed to be equal in the future. It is very rare that you should ever need to use $startdir in a PKGBUILD at all. Allan
2010/6/8 Allan McRae <allan@archlinux.org>:
It is very rare that you should ever need to use $startdir in a PKGBUILD at all.
I exclude config.h from dwm's PKGBUILD $source array and copy it from $startdir during build(). It's changed constantly so keeping it summed check is awkward, and I don't want to loose the sumcheck for the rest of sources. Maybe $sources should have a per entry ! or @ prefix that disables sum checks for that file. This could be extended to make one of the " !@" chars skip extraction, since duplicating the filenames in $noextract is less practical. Andres P
On Tue, Jun 08, 2010 at 07:58:55PM -0430, Andres P wrote:
2010/6/8 Allan McRae <allan@archlinux.org>:
It is very rare that you should ever need to use $startdir in a PKGBUILD at all.
I exclude config.h from dwm's PKGBUILD $source array and copy it from $startdir during build().
It's changed constantly so keeping it summed check is awkward, and I don't want to loose the sumcheck for the rest of sources.
Maybe $sources should have a per entry ! or @ prefix that disables sum checks for that file.
This could be extended to make one of the " !@" chars skip extraction, since duplicating the filenames in $noextract is less practical.
Andres P
Rebuilding as 'makepkg -efi' means that checksums are skipped since you're asking makepkg to use what's already extracted in $srcdir d
On Tue, Jun 8, 2010 at 8:03 PM, <d@falconindy.com> wrote:
On Tue, Jun 08, 2010 at 07:58:55PM -0430, Andres P wrote:
2010/6/8 Allan McRae <allan@archlinux.org>:
It is very rare that you should ever need to use $startdir in a PKGBUILD at all.
I exclude config.h from dwm's PKGBUILD $source array and copy it from $startdir during build().
It's changed constantly so keeping it summed check is awkward, and I don't want to loose the sumcheck for the rest of sources.
Maybe $sources should have a per entry ! or @ prefix that disables sum checks for that file.
This could be extended to make one of the " !@" chars skip extraction, since duplicating the filenames in $noextract is less practical.
Andres P
Rebuilding as 'makepkg -efi' means that checksums are skipped since you're asking makepkg to use what's already extracted in $srcdir
d
That does not account for PKGBUILD updates, namely $pkgver changes. bsdtar will overwrite config.h with the new extracted tar's contents If makepkg were as fluid as /usr/share/mk in *BSD, this wouldn't be such an issue. ;) Andres P
On 09/06/10 10:38, Andres P wrote:
If makepkg were as fluid as /usr/share/mk in *BSD, this wouldn't be such an issue. ;)
I have no idea what /usr/share/mk does in this regards so you will need to explain more.
On Tue, Jun 8, 2010 at 11:02 PM, Allan McRae <allan@archlinux.org> wrote:
On 09/06/10 10:38, Andres P wrote:
If makepkg were as fluid as /usr/share/mk in *BSD, this wouldn't be such an issue. ;)
I have no idea what /usr/share/mk does in this regards so you will need to explain more.
In *bsd, make sources from /usr/share/mk for packages in core/base, and in /usr/share/pkgsrc/mk (in netbsd; freebsd and obsd use ..ports/{Mk,infastructure}). This effectively couples make timestamp based builds with a nice library to handle all types of states. They have different identifiers and directories for distfiles, patches, and src files that directly reside in the ports db. The latter being the equivalent for source=() files in arch that get copied from $startdir. Their Makefiles are fully reentrant if you peruse these vars instead of using a giant source=() inclusion. The sum check is specified in another file, like Crux's .md5sums. Taking this in mind, I can declare config.h outside the distfiles directory and still have it copied to ./src, have the other files still be sum checked, and independantly build from extracted sources or decide to untar from scratch... Andres P
participants (4)
-
Allan McRae
-
Andres P
-
d＠falconindy.com
-
Ng Oon-Ee