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 <[email protected]> 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 <[email protected]> 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 >> > >
