[pacman-dev] [PATCH] makepkg: remove ability to build individual packages

[Que Quotion]

Case in point, I had some trouble pakaging several packages today.

One was libsystemd, which I've already submitted a patch for.
https://bugs.archlinux.org/task/46382

Another was libutil-lnux, which will need a little more help.
https://bugs.archlinux.org/task/46383

In both cases $pkgname was used where $pkgbase should be (fixed in an
earlier report for systemd) and then both packages use one
package_something() function to put files in place for another
package_somethingelse() function--both by moving files from $pkgdir into
$srcdir. This seems like bad practice to me, isn't necessary, and could be
done better: My proposal for systemd shortens the PKGBUILD by a few lines
and doesn't touch $srcdir.

Removing the "--pkg" feature of makepkg will only allow more bad practice
that will be harder to undo should we change our minds down the line.

On Tue, Sep 22, 2015 at 11:40 PM, Que Quotion <quequotion at gmail.com> wrote:

> In other words, rather than fix the packages to be safer and more logical,
> go ahead and let people write sloppy PKGBUILDs?
>
> For what it's worth, I think this is a bad idea.
>
> The changes needed to fix the packages are small, and this would reduce
> the ability of users to automate upgrading from ABS.
>
> On Tue, Sep 22, 2015 at 11:33 PM, Allan McRae <allan at archlinux.org> wrote:
>
>> On 23/09/15 00:20, Pierre Neidhardt wrote:
>> > I might have missed something in the previous messages, but is there any
>> > rationale on this, beside debatable worthiness?
>> >
>>
>> Many packages break when using this.
>>
>> Some are because assumptions made on build() about the value of $pkgname
>> which changes when --pkg was used.  These should use $pkgbase anyway...
>>
>> Also, there are quite a few split packages that rely on the first first
>> split-package being packaged for the rest of the package functions to
>> work.   This will become more prevalent when a way to do a "make
>> install" followed by moving files into different packages becomes
>> available (i.e. rpm packaging style - I am working on this).
>>
>> So...  essentially, it is (debatably) broken and will become more broken
>> in the future
>>
>
>