[arch-general] How to "decorate" a package build?
Hello, is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)? E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package: Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update Kind regards P.
Am 08.03.2017 um 11:45 schrieb Peter Nabbefeld:
Hello,
is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)?
E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package:
Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update
Kind regards P.
Hello, That is impossible with pacman. What you can do is create a local repository that is included in the automatic pacman upgrade. Then write a shell script that checks for updates of the arch package, merges it with your local changes, build it and add it to the repository. You should change the package name with e.g. a prefix or suffix and add the original package as a conflict to make it work properly. Now your custom version is available for the next pacman upgrade. -- A.
Am 08.03.2017 um 11:55 schrieb ProgAndy:
Am 08.03.2017 um 11:45 schrieb Peter Nabbefeld:
Hello,
is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)?
E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package:
Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update
Kind regards P.
Hello,
That is impossible with pacman.
What you can do is create a local repository that is included in the automatic pacman upgrade. Then write a shell script that checks for updates of the arch package, merges it with your local changes, build it and add it to the repository. You should change the package name with e.g. a prefix or suffix and add the original package as a conflict to make it work properly. Now your custom version is available for the next pacman upgrade.
--
A.
I've found out I could probably use PreTransaction-Hooks, but I cannot see, when exactly the hook is executed: before download, after download, or after unpacking. Regards P.
On 03/08/2017 06:04 AM, Peter Nabbefeld wrote:
I've found out I could probably use PreTransaction-Hooks, but I cannot see, when exactly the hook is executed: before download, after download, or after unpacking.
This makes no sense, hooks are part of a transaction and by definition cannot override part of that transaction... Use https://aur.archlinux.org/packages/asp-git/ Checkout a git clone of the official Firefox package, apply a custom change to the PKGBUILD, and whenever the package is updated, rebase your changes onto the official version then rebuild it. Or use customizepkg, which yaourt will automatically use to override repo packages when an override exists (and build that repo package via the ABS with customizepkg instead). -- Eli Schwartz
On Wed, Mar 8, 2017 at 10:55 AM, ProgAndy <admin@progandy.de> wrote:
Am 08.03.2017 um 11:45 schrieb Peter Nabbefeld:
Hello,
is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)? .
Hello,
That is impossible with pacman.
What you can do is create a local repository that is included in the automatic pacman upgrade. Then write a shell script that checks for updates of the arch package, merges it with your local changes, build it and add it to the repository. You should change the package name with e.g. a prefix or suffix and add the original package as a conflict to make it work properly. Now your custom version is available for the next pacman upgrade.
You can also use the PKGBUILD to change the name of the package you build and make your own version which you can customise or alter as you wish for the build process. For example build it as package called say ff (pkgname=ff ) instead of firefox, and then run it in parallel to the official build. So long users know to run ff instead of the stock version I can't see a problem with that? -- mike c
On Wed, 8 Mar 2017 11:45:37 +0100, Peter Nabbefeld wrote:
is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)?
E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package:
Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update
This isn't worth the effort, however... 1. disable updating the firefox package: /etc/pacman.conf IgnorePkg = firefox 2. write a wrapper for pacman that first compares the installed version, with the version provided by the repositories pacman -Q firefox | cut -d\ -f2 pacman -Si firefox | grep Version | cut -d: -f2 3. use the sed command, so that the wrapper could edit the version mentioned by your PKGBUILD 4. let the wrapper build and install your package 5. let the wrapper run a regular "pacman" with $@ options IMO it's easier to use apulse-git and if you should use freedesktop.org menus, to edit a desktop file to launch "apulse firefox" by a sript. Regards, Ralf
PS:
This isn't worth the effort, however...
1. disable updating the firefox package:
/etc/pacman.conf IgnorePkg = firefox
2. write a wrapper for pacman that first compares the installed version, with the version provided by the repositories
pacman -Q firefox | cut -d\ -f2 pacman -Si firefox | grep Version | cut -d: -f2
3. use the sed command, so that the wrapper could edit the version mentioned by your PKGBUILD
A better idea would be to get the official PKGBUILD by coping it from ABS and then to add ac_add_options --enable-alsa maybe behind ac_add_options --prefix=/usr since the prefix unlikely will change.
4. let the wrapper build and install your package
5. let the wrapper run a regular "pacman" with $@ options
IMO it's easier to use apulse-git and if you should use freedesktop.org menus, to edit a desktop file to launch "apulse firefox" by a sript.
Am 08.03.2017 um 12:02 schrieb Ralf Mardorf:
On Wed, 8 Mar 2017 11:45:37 +0100, Peter Nabbefeld wrote:
is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)?
E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package:
Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update
This isn't worth the effort, however...
1. disable updating the firefox package:
/etc/pacman.conf IgnorePkg = firefox
2. write a wrapper for pacman that first compares the installed version, with the version provided by the repositories
pacman -Q firefox | cut -d\ -f2 pacman -Si firefox | grep Version | cut -d: -f2
3. use the sed command, so that the wrapper could edit the version mentioned by your PKGBUILD
4. let the wrapper build and install your package
5. let the wrapper run a regular "pacman" with $@ options
IMO it's easier to use apulse-git and if you should use freedesktop.org menus, to edit a desktop file to launch "apulse firefox" by a sript.
Regards, Ralf
Thank You! However, while one part is about Firefox, the other is about changing builds while still getting the signalling for new builds from pacman. One possibility seems to use Hooks, while I'm not yet sure how to use them correctly. Regards P.
Am 08.03.2017 um 12:20 schrieb Peter Nabbefeld:
Thank You! However, while one part is about Firefox, the other is about changing builds while still getting the signalling for new builds from pacman.
One possibility seems to use Hooks, while I'm not yet sure how to use them correctly.
Regards P.
Hooks don't work too well if you want to modify a package. Ralf has a good idea, I would change it a bit and do it like this: #!/bin/bash # 1) set pacman to ignore firefox upgrades # 2) perform normal pacman upgrade sudo pacman -Syu # 3) continue this script # pacman should still recognize that firefox is out of date even if the update is disabled if [ pacman -Qu firefox ]; then # download PKGBUILD from abs # patch PKGBUILD # build # install fi -- A.
Am 08.03.2017 um 12:30 schrieb ProgAndy:
Am 08.03.2017 um 12:20 schrieb Peter Nabbefeld:
Thank You! However, while one part is about Firefox, the other is about changing builds while still getting the signalling for new builds from pacman.
One possibility seems to use Hooks, while I'm not yet sure how to use them correctly.
Regards P.
Hooks don't work too well if you want to modify a package. Ralf has a good idea, I would change it a bit and do it like this:
#!/bin/bash # 1) set pacman to ignore firefox upgrades # 2) perform normal pacman upgrade sudo pacman -Syu # 3) continue this script
# pacman should still recognize that firefox is out of date even if the update is disabled if [ pacman -Qu firefox ]; then # download PKGBUILD from abs # patch PKGBUILD # build # install fi
--
A.
Thank You, I'll try that! Regards P.
On Wed, 8 Mar 2017 12:48:14 +0100 Peter Nabbefeld <peter.nabbefeld@gmx.de> wrote:
Thank You, I'll try that!
Regards P.
You do realize that firefox is now built with alsa support in the repos, right?
Am 08.03.2017 um 15:34 schrieb Doug Newgard:
On Wed, 8 Mar 2017 12:48:14 +0100 Peter Nabbefeld <peter.nabbefeld@gmx.de> wrote:
Thank You, I'll try that!
Regards P.
You do realize that firefox is now built with alsa support in the repos, right?
Yes, I already wondered about this when looking at the PKGBUIL source file, because it seemed a decision has been made against it, but the subject is "How to "decorate" a package build?" - firefox has only been a package which has been discussed before. So, the most important result for me is, I've learned some interesting details about the package system. Kind regards Peter
On 03/08/2017 03:34 PM, Peter Nabbefeld wrote:
Yes, I already wondered about this when looking at the PKGBUIL source file, because it seemed a decision has been made against it, but the subject is "How to "decorate" a package build?" - firefox has only been a package which has been discussed before.
So, the most important result for me is, I've learned some interesting details about the package system.
And the answer is, you're not the first person to want something like that: - customizepkg provides a framework for applying differences to packages - yaourt is capable of autodetecting a repo package that has a customizepkg configuration, and building that package from source instead of syncing the prebuilt package. -- Eli Schwartz
Am 08.03.2017 um 23:12 schrieb Eli Schwartz via arch-general:
On 03/08/2017 03:34 PM, Peter Nabbefeld wrote:
Yes, I already wondered about this when looking at the PKGBUIL source file, because it seemed a decision has been made against it, but the subject is "How to "decorate" a package build?" - firefox has only been a package which has been discussed before.
So, the most important result for me is, I've learned some interesting details about the package system.
And the answer is, you're not the first person to want something like that: - customizepkg provides a framework for applying differences to packages
Hm, there's incomplete documentation about this, especially about how to override PKGBUILDs. E.g. for firefox: Would I have to name the file "firefox-52.0-2-x86_64", "firefox-52.0-2", "firefox-52.0", "firefox-52", or just "firefox"?
- yaourt is capable of autodetecting a repo package that has a customizepkg configuration, and building that package from source instead of syncing the prebuilt package.
I'm currently using pacaur - what do I have to be aware of when changing to yaourt? Kind regards P.
On Thu, 9 Mar 2017 09:02:23 +0100, Peter Nabbefeld wrote:
I'm currently using pacaur - what do I have to be aware of when changing to yaourt?
You should be aware that both aren't official Arch tools :D. SICR. I'm a yaourt user, but do a lot of things with official Arch tools and wouldn't count on an unofficial helper.
On Wed, 8 Mar 2017 12:30:25 +0100, ProgAndy wrote:
Ralf has a good idea, I would change it a bit and do it like this:
#!/bin/bash # 1) set pacman to ignore firefox upgrades # 2) perform normal pacman upgrade sudo pacman -Syu # 3) continue this script
# pacman should still recognize that firefox is out of date even if the update is disabled if [ pacman -Qu firefox ]; then # download PKGBUILD from abs # patch PKGBUILD # build # install fi
There are several ways to write a wrapper, but indeed the first thing before building firefox is to upgrade. Anyway, all solutions to automatically build firefox are IMO not worth the effort, since "apulse-git" does the job. If it shouldn't work for the OP, it might be easy to fix. Assuming troubleshooting should be required, I would start with running $ aplay -l | grep "card 0" and $ cat /etc/modprobe.d/*alsa* Regards, Ralf
participants (6)
-
Doug Newgard
-
Eli Schwartz
-
Mike Cloaked
-
Peter Nabbefeld
-
ProgAndy
-
Ralf Mardorf