[arch-general] Best Practices...
I have a question about Best Practices or... a clean way of handeling these types of scenarios... I've seen this come up with several packages.... If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that. x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104. Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package). Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105). When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue. from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count). from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems. is instructing the user to pull the abs source the solution? -- csgeek
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git -- Ionuț
* Ionuț Bîru <ibiru@archlinux.org> [28.09.2010 17:41]:
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git and put mplayer into IgnorePkg in the /etc/pacman.conf This way pacman will spit out a warning as soon as there's an update available for mplayer, but doesn't actually update it. You simply have to wait for this message, build mplayer again by yourself with the newer PKGBUILD from abs and you're good.
On Tue, 2010-09-28 at 20:19 +0200, uli.armbruster@googlemail.com wrote:
* Ionuț Bîru <ibiru@archlinux.org> [28.09.2010 17:41]:
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git and put mplayer into IgnorePkg in the /etc/pacman.conf This way pacman will spit out a warning as soon as there's an update available for mplayer, but doesn't actually update it. You simply have to wait for this message, build mplayer again by yourself with the newer PKGBUILD from abs and you're good.
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
* Ng Oon-Ee <ngoonee@gmail.com> [28.09.2010 21:07]:
On Tue, 2010-09-28 at 20:19 +0200, uli.armbruster@googlemail.com wrote:
* Ionuț Bîru <ibiru@archlinux.org> [28.09.2010 17:41]:
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git and put mplayer into IgnorePkg in the /etc/pacman.conf This way pacman will spit out a warning as soon as there's an update available for mplayer, but doesn't actually update it. You simply have to wait for this message, build mplayer again by yourself with the newer PKGBUILD from abs and you're good.
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =) Right! I used bauerbill for a few days, but seems like I forgot about this functionality ;-)
Excerpts from Ng Oon-Ee's message of 2010-09-28 21:06:57 +0200:
On Tue, 2010-09-28 at 20:19 +0200, uli.armbruster@googlemail.com wrote:
* Ionuț Bîru <ibiru@archlinux.org> [28.09.2010 17:41]:
On 09/28/2010 06:39 PM, Samir wrote:
I have a question about Best Practices or... a clean way of handeling these types of scenarios...
I've seen this come up with several packages....
If I install mplayer and x264 from pacman, but then pull x264-git from aur, and install that.
x264 conflicts with x264-git which makes sense.. but then mplayer suddenly is broken because libx264.so.104.
Basically mplayer isn't aware that x264-git (which naturally conflicts with the x264 package).
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
When I was on a purely from source distro, I'd just force a rebuild of mplayer and its dependencies...and that would fixed the issue.
from a user perspective: what's the solution to these types of situations. (creating a symlink to the .so file doesn't count).
from a packager perspective: Should we do anything in particular to take these sorts of situations into account and try to avoid some of these problems.
is instructing the user to pull the abs source the solution?
-- csgeek
use abs to recompile mplayer against x264-git and put mplayer into IgnorePkg in the /etc/pacman.conf This way pacman will spit out a warning as soon as there's an update available for mplayer, but doesn't actually update it. You simply have to wait for this message, build mplayer again by yourself with the newer PKGBUILD from abs and you're good.
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
I'm curious, what can it actually do? Build from ABS, ok, but automatically with my modifications? What about alternative packages only found in AUR?
On 29 September 2010 03:33, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Ng Oon-Ee's message of 2010-09-28 21:06:57 +0200:
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
I'm curious, what can it actually do? Build from ABS, ok, but automatically with my modifications? What about alternative packages only found in AUR?
Check out the features: "* option to trust specific AUR users to fully automate AUR package building" From: http://xyne.archlinux.ca/projects/bauerbill/
Excerpts from Ray Rashif's message of 2010-09-28 23:19:19 +0200:
On 29 September 2010 03:33, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Ng Oon-Ee's message of 2010-09-28 21:06:57 +0200:
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
I'm curious, what can it actually do? Build from ABS, ok, but automatically with my modifications? What about alternative packages only found in AUR?
Check out the features:
"* option to trust specific AUR users to fully automate AUR package building"
Ok, but what does this mean? I see a list of features but it's hard to get see use cases from a list. Trust an AUR user means I can for example trust myself and have it build a package from my sources. That's pretty much all it tells me. It doesn't tell me whether it solves any of my problems, whether it can do something like automatically building the latest version of packages with the options I want.
On Wed, 2010-09-29 at 00:12 +0200, Philipp Überbacher wrote:
Excerpts from Ray Rashif's message of 2010-09-28 23:19:19 +0200:
On 29 September 2010 03:33, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Ng Oon-Ee's message of 2010-09-28 21:06:57 +0200:
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
I'm curious, what can it actually do? Build from ABS, ok, but automatically with my modifications? What about alternative packages only found in AUR?
Check out the features:
"* option to trust specific AUR users to fully automate AUR package building"
Ok, but what does this mean? I see a list of features but it's hard to get see use cases from a list.
Trust an AUR user means I can for example trust myself and have it build a package from my sources. That's pretty much all it tells me. It doesn't tell me whether it solves any of my problems, whether it can do something like automatically building the latest version of packages with the options I want.
You can specify a patchdir which makes automatic modifications to the PKGBUILD. Its less useful than it sounds though, would prefer a bit more flexibility (like a 'hook' running some sed commands), but its great as-is. So for example you can set it to 'always-build' mplayer, when there's an mplayer update that's what it will do. If there's a relevant patch in your PATCHDIR (or whatever its called now) that'll be applied. Trusting an AUR user simply means no prompt for 'are you sure you want to compile this, please check it first' for packages from said user.
Excerpts from Ng Oon-Ee's message of 2010-09-29 00:55:12 +0200:
On Wed, 2010-09-29 at 00:12 +0200, Philipp Überbacher wrote:
Excerpts from Ray Rashif's message of 2010-09-28 23:19:19 +0200:
On 29 September 2010 03:33, Philipp Überbacher <hollunder@lavabit.com> wrote:
Excerpts from Ng Oon-Ee's message of 2010-09-28 21:06:57 +0200:
Or use bauerbill and set mplayer to automatically compile from abs if there's an update =)
I'm curious, what can it actually do? Build from ABS, ok, but automatically with my modifications? What about alternative packages only found in AUR?
Check out the features:
"* option to trust specific AUR users to fully automate AUR package building"
Ok, but what does this mean? I see a list of features but it's hard to get see use cases from a list.
Trust an AUR user means I can for example trust myself and have it build a package from my sources. That's pretty much all it tells me. It doesn't tell me whether it solves any of my problems, whether it can do something like automatically building the latest version of packages with the options I want.
You can specify a patchdir which makes automatic modifications to the PKGBUILD. Its less useful than it sounds though, would prefer a bit more flexibility (like a 'hook' running some sed commands), but its great as-is.
So for example you can set it to 'always-build' mplayer, when there's an mplayer update that's what it will do. If there's a relevant patch in your PATCHDIR (or whatever its called now) that'll be applied.
This sounds pretty much like 'works fine as long as the maintainer only changes the version number'. Correct?
Trusting an AUR user simply means no prompt for 'are you sure you want to compile this, please check it first' for packages from said user.
Ok, so that's rather irrelevant. Thanks for the info, I currently use slurpy for AUR stuff and IgnorePkg for stuff that needs manual builds. It sounds as if bauerpill might help to improve the situation a little bit, so again, thanks.
On Tue, 28 Sep 2010 18:41:20 +0300, Ionu?^? Bîru <ibiru@archlinux.org> wrote:
use abs to recompile mplayer against x264-git
That would be a good solution for most packages but in this case you should be aware that: - x264 is used only for video encoding, not decoding, so unless you encode videos you simply don't need x264-git; - if you *do* encode videos and care about performance you should compile mplayer on your machine with a custom PKGBUILD or one from AUR that lets its build process auto-detect your hardware. mplayer-svn is probably a good choice. -- Pierre 'catwell' Chapuis
On 28.09.2010 17:39, Samir wrote:
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
Normally that number only changes if the libraries aren't compatible anymore. That means mplayer might break completely or behave strange if you mess with that. Linking to libx264.so would be the same as creating a symlink from 104 to 105 btw. -- Florian Pritz -- {flo,bluewind}@server-speed.net
Fair enough. I was trying to think if there's a cleaner way of avoiding breakage. I found http://aur.archlinux.org/packages.php?ID=15982 which seems to provide some sanity. I was trying to think if there's anything, as a packager, that I could do to prevent or mitigate dll hell (.so hell? ) -- csgeek On Tue, Sep 28, 2010 at 10:46 AM, Florian Pritz <bluewind@server-speed.net> wrote:
On 28.09.2010 17:39, Samir wrote:
Now, to be fair.. mplayer probably should have been linked against libx264.so rather then libx264.so.104 (-git package provides a libx264.so.105).
Normally that number only changes if the libraries aren't compatible anymore. That means mplayer might break completely or behave strange if you mess with that.
Linking to libx264.so would be the same as creating a symlink from 104 to 105 btw. -- Florian Pritz -- {flo,bluewind}@server-speed.net
On 28.09.2010 18:46, Samir wrote:
I was trying to think if there's anything, as a packager, that I could do to prevent or mitigate dll hell (.so hell? )
Some time ago I wrote a patch to add special dependencies to packages so that issue is being worked on. What's the status Allan? PS: Please don't top post. -- Florian Pritz -- {flo,bluewind}@server-speed.net
participants (8)
-
Florian Pritz
-
Ionuț Bîru
-
Ng Oon-Ee
-
Philipp Überbacher
-
Pierre Chapuis
-
Ray Rashif
-
Samir
-
uli.armbruster＠googlemail.com