Package customization features for makepkg script

Jack_Black · 2018-12-21 17:20:07

Hello, ArchLinux hackers!

I have accomplished new features for makepkg. I added some Gentoo-like package dependency selection, but in interactive mode (customization Wizard). And now I am looking for persons, who can take a look at my source code, try to launch it and send me a feedbacks.

I published the source code on GitHub https://github.com/ezamlinsky/pacman, and made a testing package on AUR https://aur.archlinux.org/packages/pacm … insky-git/
Here you may find new features description page and brief overview of the project. https://github.com/ezamlinsky/pacman/wi … n-features

Looking forward for your comments.

P. S. Have a Merry Christmas and good hackings.

Last edited by Jack_Black (2018-12-21 19:14:05)

Trilby · 2018-12-21 17:25:50

I'm confused about the point of all this:

github README wrote:

New makepkg has 2 additional options: -t|(--tune) and -u|(--update).
Tune option allows you interactively tune package dependencies, before compilation and following installation. Update option does package upgrade up to new version, but keeps all previously set dependencies. It is very important when you update customized package, and wish to not configure it again and again, each time a new version is released.

Tune can already be accomplished more simply by editing the PKGBUILD. And update makes no sense, once one has edited a PKGBUILD to make a customized package, they wouldn't need to configure it again and again to update, they'd just run `makepkg` in the directory where that customized PKGBUILD was kept.

As for "dependency tracking" you seem to take issue with namcap, yet you wrote something that does essentially the exact same thing. You certainly are allowed to reinevent the wheel, but when you do you can't really market it as some brand new innovation.

Last edited by Trilby (2018-12-21 17:28:16)

jasonwryan · 2018-12-21 17:45:17

Moving to Community Contributions...

Jack_Black · 2018-12-21 17:52:08

namcap is good manual tool. What if you forgot to launch it.
I think if you do same thing every time, then you should automate it in some way.

About package updates.
If you have a workstation, you configured with some additional cURL dependencies. When a package maintainer release a new version. What you have to do?
Should I change PKGBUILD again? And add some additional configure script rules for special packages I use.
Or I simply type makepkg --update and job is done. Target package will be upgraded up to new version. And all dependencies I set are preserved from last compilation and installation stage.
It is an easy and elegant way to create packages for set of ArchLinux servers and Workstations.
Be lazy monkey. Do less, get more :-)

Trilby · 2018-12-21 17:59:13

Jack_Black wrote:

When a package maintainer release a new version. What you have to do?

For any PKGBUILD that I've modified, I am the package maintainer. But if you mean what do I have to do when there is a new upstream version available? If it is a VCS package, nothing other than running `makepkg`. If it is not a VCS package, I change the pkgver variable then run `makepkg`. That's it.

Scimmia · 2018-12-21 18:15:52

That's a HORRIBLE name for the AUR package, and it should be deleted just because of that. It is not a testing version of pacman, it's your own, personal fork.

Jack_Black · 2018-12-21 18:38:04

Hi, Trilby

Seems, we do not understand each other.
I'm trying to explain you Gentoo feature that I would like to port for ArchLinux (in more nicely way).
In Gentoo if you configured a package with system wide USE flag, and then a new version is available. Then you just do program recompilation.
All dependencies are preserved. The same USE flags are go trough the compilation process. And you will get the new version with all features you have configured last time.

This is meaning of new --update option. Thus I developed syntax extension to makepkg "depends" array.
You may specify that a package you maintain has additional dependencies (Arch now uses optional array in makepkg script to track them).
An end user, who will build program from source, will be able to choose what additional functional (packages) he needs to be linked with this program.
Update will preserve these dependencies after package upgrade. It will recompile a program with the same packages as before. And you will not lost all of libraries after pacman -R `pacman -Qdtq`

Jack_Black · 2018-12-21 18:42:19

Scimmia wrote:

That's a HORRIBLE name for the AUR package, and it should be deleted just because of that. It is not a testing version of pacman, it's your own, personal fork.

Thank you for fast feedback. Will rename it in something more convenient. Like pacman-ezamlinsky-git.

Done. Deletion request is sent for old package.

Last edited by Jack_Black (2018-12-21 19:21:20)

eschwartz · 2018-12-21 20:04:31

Jack_Black wrote:

Hi, Trilby
Seems, we do not understand each other.
I'm trying to explain you Gentoo feature that I would like to port for ArchLinux (in more nicely way).
In Gentoo if you configured a package with system wide USE flag, and then a new version is available. Then you just do program recompilation.
All dependencies are preserved. The same USE flags are go trough the compilation process. And you will get the new version with all features you have configured last time.
This is meaning of new --update option. Thus I developed syntax extension to makepkg "depends" array.
You may specify that a package you maintain has additional dependencies (Arch now uses optional array in makepkg script to track them).
An end user, who will build program from source, will be able to choose what additional functional (packages) he needs to be linked with this program.
Update will preserve these dependencies after package upgrade. It will recompile a program with the same packages as before. And you will not lost all of libraries after pacman -R `pacman -Qdtq`

Since the PKGBUILD format is a subset of bash, it is definitively possible to emulate Gentoo USE flags in the following manner:

_use_feature=

pkgname=testpkg
pkgver=1
pkgrel=1
pkgdesc="experiment with makepkg USE flags"
arch=('x86_64')
url="http://localhost.localdomain"
license=('Public_Domain')
source=("${url}/files/${pkgname}-${pkgver}.tar.gz")
sha256sums=('f5a39830d9b086c6ae6cfc821d54a5b1d2c7c725a44bb9e210a0730fc1f70d58')

if [[ ${_use_feature} = 1 ]]; then
    depends+=("featurepkg")
    config_opts+=('--with-feature')
fi

build() {
    cd "${srcdir}"/${pkgname}-${pkgver}

    ./configure --prefix=/usr \
                --sysconfdir=/etc \
                --localstatedir=/var \
                "${config_opts[@]}"

    make
}

package() {
    cd "${srcdir}"/${pkgname}-${pkgver}

    make DESTDIR="${pkgdir}" install
}

I promise you that we won't accept code to make makepkg itself offer you config prompts and edit the PKGBUILD. It's theoretically possible we might standardize on helper functions similar to the ones that Gentoo has, and a configuration directory to source such USE flags from, but what you're proposing doesn't really resemble either Arch Linux or Gentoo.

Replacing namcap like that is completely not going to happen. There are tentative plans to offer pkglint as a replacement for namcap that is integrated directly into makepkg itself, but any and all use of dependency specification will always remain the responsibility of the PKGBUILD author.

Last edited by eschwartz (2018-12-21 20:06:23)

Trilby · 2018-12-21 20:35:20

Jack_Black wrote:

All dependencies are preserved. The same USE flags are go trough the compilation process. And you will get the new version with all features you have configured last time.

Yes. And you'd get this same result by simply incrementing the pkgver function of the existing PKGBUILD. That's it. Before you come in and try to change everything to make it work more like Gentoo, perhaps you should actually learn how to use Arch linux properly first.

Last edited by Trilby (2018-12-21 21:06:09)

Jack_Black · 2018-12-21 21:02:06

Got it.
Any way, thank you.
I was glad to get a fast feedback from all of you. The thread can be closed now.
P.S. Have a Merry Christmas.

Arch Linux

#1 2018-12-21 17:20:07

Package customization features for makepkg script

Hello, ArchLinux hackers!

#2 2018-12-21 17:25:50

Re: Package customization features for makepkg script

#3 2018-12-21 17:45:17

Re: Package customization features for makepkg script

#4 2018-12-21 17:52:08

Re: Package customization features for makepkg script

#5 2018-12-21 17:59:13

Re: Package customization features for makepkg script

#6 2018-12-21 18:15:52

Re: Package customization features for makepkg script

#7 2018-12-21 18:38:04

Re: Package customization features for makepkg script

#8 2018-12-21 18:42:19

Re: Package customization features for makepkg script

#9 2018-12-21 20:04:31

Re: Package customization features for makepkg script

#10 2018-12-21 20:35:20

Re: Package customization features for makepkg script

#11 2018-12-21 21:02:06

Re: Package customization features for makepkg script

Board footer