I was wondering if it is possible to redirect one package to another, and if it was possible in unsupported.
For example, python bindings for poppler are currently, but probably will stay like this, a bazaar repository. The fact is, as it is the official way of obtaining the software, the package should be python-poppler. But, as it is a bzr, it should be python-poppler-bzr too and so will beneficiate the makepkg functionality to update to the last repository version.
Another package needs the bindings, but as it is the functionnality that are needed and not a particular way of obtention, I think it is better to request python-poppler. So, for the requirement to be installed automatically, it is better for the package to be named python-poppler.
Finally, it could be great if the package python-poppler was redirected to python-poppler-bzr. And if a stable packaged version of the software arise, the two packages could be dissociated transparently.
Is it possible ?
Cilyan
Cilyan Olowen wrote:
I was wondering if it is possible to redirect one package to another, and if it was possible in unsupported.
For example, python bindings for poppler are currently, but probably will stay like this, a bazaar repository. The fact is, as it is the official way of obtaining the software, the package should be python-poppler. But, as it is a bzr, it should be python-poppler-bzr too and so will beneficiate the makepkg functionality to update to the last repository version.
Another package needs the bindings, but as it is the functionnality that are needed and not a particular way of obtention, I think it is better to request python-poppler. So, for the requirement to be installed automatically, it is better for the package to be named python-poppler.
Finally, it could be great if the package python-poppler was redirected to python-poppler-bzr. And if a stable packaged version of the software arise, the two packages could be dissociated transparently.
Is it possible ?
Cilyan
"man PKGBUILD" and look at provides. Probably want to set conflicts too.
Allan
Thanks, but as far as I know (it's restrictive !) the "provides" array does not allow pacman or any other AUR building tool to find a replacement package if the one that it is looking for does not exist.
I mean, I'm not looking for an option to say "I provide this" but rather "You won't find that, but try this, it will provide what you are looking for".
Cilyan
2009/3/24 Allan McRae allan@archlinux.org:
Cilyan Olowen wrote:
I was wondering if it is possible to redirect one package to another, and if it was possible in unsupported.
For example, python bindings for poppler are currently, but probably will stay like this, a bazaar repository. The fact is, as it is the official way of obtaining the software, the package should be python-poppler. But, as it is a bzr, it should be python-poppler-bzr too and so will beneficiate the makepkg functionality to update to the last repository version.
Another package needs the bindings, but as it is the functionnality that are needed and not a particular way of obtention, I think it is better to request python-poppler. So, for the requirement to be installed automatically, it is better for the package to be named python-poppler.
Finally, it could be great if the package python-poppler was redirected to python-poppler-bzr. And if a stable packaged version of the software arise, the two packages could be dissociated transparently.
Is it possible ?
Cilyan
"man PKGBUILD" and look at provides. Probably want to set conflicts too.
Allan
On Tue, Mar 24, 2009 at 9:57 AM, Cilyan Olowen gaknar@gmail.com wrote:
Thanks, but as far as I know (it's restrictive !) the "provides" array does not allow pacman or any other AUR building tool to find a replacement package if the one that it is looking for does not exist.
I mean, I'm not looking for an option to say "I provide this" but rather "You won't find that, but try this, it will provide what you are looking for".
Cilyan
at least pacman does , for example ###### sudo pacman -S efreet warning: provider package was selected (efreet-svn provides efreet) ###### not sure about AUR building tools, I don't use them.
Ronald
Ah, okay, I didn't know pacman could do that. So this answers my question :)
Thanks a lot !
2009/3/24 Ronald van Haren pressh@gmail.com:
On Tue, Mar 24, 2009 at 9:57 AM, Cilyan Olowen gaknar@gmail.com wrote:
Thanks, but as far as I know (it's restrictive !) the "provides" array does not allow pacman or any other AUR building tool to find a replacement package if the one that it is looking for does not exist.
I mean, I'm not looking for an option to say "I provide this" but rather "You won't find that, but try this, it will provide what you are looking for".
Cilyan
at least pacman does , for example ###### sudo pacman -S efreet warning: provider package was selected (efreet-svn provides efreet) ###### not sure about AUR building tools, I don't use them.
Ronald
On Tue, Mar 24, 2009 at 12:56:20AM +0100, Cilyan Olowen wrote:
I was wondering if it is possible to redirect one package to another, and if it was possible in unsupported.
For example, python bindings for poppler are currently, but probably will stay like this, a bazaar repository. The fact is, as it is the official way of obtaining the software, the package should be python-poppler. But, as it is a bzr, it should be python-poppler-bzr too and so will beneficiate the makepkg functionality to update to the last repository version.
Another package needs the bindings, but as it is the functionnality that are needed and not a particular way of obtention, I think it is better to request python-poppler. So, for the requirement to be installed automatically, it is better for the package to be named python-poppler.
Finally, it could be great if the package python-poppler was redirected to python-poppler-bzr. And if a stable packaged version of the software arise, the two packages could be dissociated transparently.
The AUR doesn't store any of the provides data, so it isn't possible in unsupported. This would definitely be a feature to consider though.
aur-general@lists.archlinux.org