Discussion:
How to "decorate" a package build?
(too old to reply)
Peter Nabbefeld
2017-03-08 10:45:37 UTC
Permalink
Raw Message
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.
ProgAndy
2017-03-08 10:55:41 UTC
Permalink
Raw Message
Post by 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
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.
Peter Nabbefeld
2017-03-08 11:04:51 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
Post by 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
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.
Eli Schwartz via arch-general
2017-03-08 11:49:09 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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
Mike Cloaked via arch-general
2017-03-08 11:30:48 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
Post by 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
Ralf Mardorf
2017-03-08 11:02:42 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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
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
Ralf Mardorf
2017-03-08 11:14:51 UTC
Permalink
Raw Message
Post by Ralf Mardorf
This isn't worth the effort, however...
/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.
Post by Ralf Mardorf
4. let the wrapper build and install your package
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.
Peter Nabbefeld
2017-03-08 11:20:10 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by Peter Nabbefeld
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
Official Package Changed --«Signal»--> Private Package Update
--«Inherits»--> Official Package Update
This isn't worth the effort, however...
/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
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.
ProgAndy
2017-03-08 11:30:25 UTC
Permalink
Raw Message
Post by 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.
Peter Nabbefeld
2017-03-08 11:48:14 UTC
Permalink
Raw Message
Post by ProgAndy
Post by 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
#!/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.
Doug Newgard
2017-03-08 14:34:56 UTC
Permalink
Raw Message
On Wed, 8 Mar 2017 12:48:14 +0100
Post by Peter Nabbefeld
Thank You, I'll try that!
Regards
P.
You do realize that firefox is now built with alsa support in the repos, right?
Peter Nabbefeld
2017-03-08 20:34:15 UTC
Permalink
Raw Message
Post by Doug Newgard
On Wed, 8 Mar 2017 12:48:14 +0100
Post by Peter Nabbefeld
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
Eli Schwartz via arch-general
2017-03-08 22:12:13 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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
Peter Nabbefeld
2017-03-09 08:02:23 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by Peter Nabbefeld
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.
- 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"?
Post by Eli Schwartz via arch-general
- 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.
Ralf Mardorf
2017-03-09 11:43:43 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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.

Ralf Mardorf
2017-03-08 12:37:54 UTC
Permalink
Raw Message
Post by ProgAndy
#!/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
Loading...