[aur-general] How to handle interchangeable dependencies?
Hi there. I'm looking for a clean way to handle packages that can replace others. Examples: lash can be substituted by lash-git, it works fine, except namcap complains: hydrogen-svn E: Dependency detected and not included (lash-git) from files ['usr/bin/hydrogen'] hydrogen-svn W: Dependency included and not needed (lash) Adding 'lash' or 'lash=0.6.0' to the provides array of lash-git doesn't help. I have the same situation with for example jack-audio-connection-kit where we have quite a number of different packages that all provide the same basic functionality and are interchangeable. Note that it mostly works with provides, it just isn't clean and there are cases where it can break stuff. Is there a solution to this? Best regards, Philipp
hollunder@gmx.at wrote:
Hi there. I'm looking for a clean way to handle packages that can replace others. Examples: lash can be substituted by lash-git, it works fine, except namcap complains:
hydrogen-svn E: Dependency detected and not included (lash-git) from files ['usr/bin/hydrogen'] hydrogen-svn W: Dependency included and not needed (lash)
Adding 'lash' or 'lash=0.6.0' to the provides array of lash-git doesn't help. I have the same situation with for example jack-audio-connection-kit where we have quite a number of different packages that all provide the same basic functionality and are interchangeable.
Note that it mostly works with provides, it just isn't clean and there are cases where it can break stuff. Is there a solution to this?
I think this is more a limitation in namcap than your package. I think a bug report for namcap would be appropriate. Allan
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman. 2009/4/6 Allan McRae <allan@archlinux.org>
hollunder@gmx.at wrote:
Hi there. I'm looking for a clean way to handle packages that can replace others. Examples: lash can be substituted by lash-git, it works fine, except namcap complains:
hydrogen-svn E: Dependency detected and not included (lash-git) from files ['usr/bin/hydrogen'] hydrogen-svn W: Dependency included and not needed (lash)
Adding 'lash' or 'lash=0.6.0' to the provides array of lash-git doesn't help. I have the same situation with for example jack-audio-connection-kit where we have quite a number of different packages that all provide the same basic functionality and are interchangeable.
Note that it mostly works with provides, it just isn't clean and there are cases where it can break stuff. Is there a solution to this?
I think this is more a limitation in namcap than your package. I think a bug report for namcap would be appropriate.
Allan
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem.... The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough. Allan
On Mon, 06 Apr 2009 21:46:48 +1000 Allan McRae <allan@archlinux.org> wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem....
The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least related. Concrete example: lash-git: provides=('lash=0.6.0') calf-git: depends=('fluidsynth' 'libglade' 'lash>=0.6.0') namcap calf-git-20090406-1-i686.pkg.tar.gz calf-git E: Dependency detected and not included (lash-git) from files ['usr/bin/calfjackhost'] calf-git W: Dependency included and not needed (lash) Best regards, Philipp
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000 Allan McRae <allan@archlinux.org> wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem....
The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least related. Concrete example: lash-git: provides=('lash=0.6.0') calf-git: depends=('fluidsynth' 'libglade' 'lash>=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz calf-git E: Dependency detected and not included (lash-git) from files ['usr/bin/calfjackhost'] calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is a limitation of namcap and it would be good to file a feature request to get it fixed. The other "problem" is a PKGBUILD with incomplete provides encountering a versioned dependency. Completely different. Allan
On Mon, 06 Apr 2009 22:32:48 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000 Allan McRae <allan@archlinux.org> wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem....
The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least related. Concrete example: lash-git: provides=('lash=0.6.0') calf-git: depends=('fluidsynth' 'libglade' 'lash>=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz calf-git E: Dependency detected and not included (lash-git) from files ['usr/bin/calfjackhost'] calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is a limitation of namcap and it would be good to file a feature request to get it fixed.
The other "problem" is a PKGBUILD with incomplete provides encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help. As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already. Philipp
On Mon, Apr 6, 2009 at 08:42, <hollunder@gmx.at> wrote:
Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already.
Philipp
Yaourt isn't an officially supported tool. Have you tried by downloading the package and then using makepkg -i? I suspect that yaourt is the source of this bug.
On Mon, 6 Apr 2009 08:44:38 -0400 Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Mon, Apr 6, 2009 at 08:42, <hollunder@gmx.at> wrote:
Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already.
Philipp
Yaourt isn't an officially supported tool. Have you tried by downloading the package and then using makepkg -i? I suspect that yaourt is the source of this bug.
both packages, lash-git and calf-git are so far only local so far, I'll upload and try calf-git for the sake of this experiment. Philipp
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 22:32:48 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000 Allan McRae <allan@archlinux.org> wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem....
The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least related. Concrete example: lash-git: provides=('lash=0.6.0') calf-git: depends=('fluidsynth' 'libglade' 'lash>=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz calf-git E: Dependency detected and not included (lash-git) from files ['usr/bin/calfjackhost'] calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is a limitation of namcap and it would be good to file a feature request to get it fixed.
The other "problem" is a PKGBUILD with incomplete provides encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already.
It should not. If it does, then it is a bug in yaourt. If you have lash-git installed, then build calf-git manually using and installed it with "pacman -U <pkg>", there should be no complaints from pacman. Allan
On Mon, 06 Apr 2009 22:48:53 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 22:32:48 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000 Allan McRae <allan@archlinux.org> wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package "brasero-lite". It is brasero but without the gnome dependencies, and has the provides=('brasero'), but when I try and install a package that has brasero as a dependencie, such as sound-juicer, pacman attempts to install brasero, not realising that i allready have brasero-lite. This isn't a sound juicer fault, it is a fault in pacman.
That is a different problem....
The brasero-lite PKGBUILD should have provides=("brasero=2.26.0") in it. Sound-juicer requires "brasero>=2.26.0" so just providing brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least related. Concrete example: lash-git: provides=('lash=0.6.0') calf-git: depends=('fluidsynth' 'libglade' 'lash>=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz calf-git E: Dependency detected and not included (lash-git) from files ['usr/bin/calfjackhost'] calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is a limitation of namcap and it would be good to file a feature request to get it fixed.
The other "problem" is a PKGBUILD with incomplete provides encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already.
It should not. If it does, then it is a bug in yaourt. If you have lash-git installed, then build calf-git manually using and installed it with "pacman -U <pkg>", there should be no complaints from pacman.
Allan
==> calf-git dependencies: - fluidsynth (already installed) - libglade (already installed) - lash (building from AUR) So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. Thanks for your help with that Allan and Daenyth.
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts. Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/ Philipp
2009/4/6 <hollunder@gmx.at>:
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts.
Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/
Report the bug in the "Arch Linux" section of the bugtracker and remember to put namcap in the bug title. http://abhidg.mine.nu is my home website which has namcap-reports (a web interface showing namcap errors and warnings). It has nothing to do with the actual namcap program. -- Abhishek
On Mon, 6 Apr 2009 19:18:55 +0530 Abhishek Dasgupta <abhidg@gmail.com> wrote:
2009/4/6 <hollunder@gmx.at>:
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts.
Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/
Report the bug in the "Arch Linux" section of the bugtracker and remember to put namcap in the bug title.
http://abhidg.mine.nu is my home website which has namcap-reports (a web interface showing namcap errors and warnings). It has nothing to do with the actual namcap program.
Ah, sorry, and thanks. I got kind of mislead because this seems to be the only wiki page related to namcap http://wiki.archlinux.org/index.php/Namcap_Reports Philipp
On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish).
It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh. Namcap is a supported script by the way.
Does one know how to report bugs for namcap?
Arch Linux bug tracker: http://bugs.archlinux.org/index.php?project=1&do=index&switch=1
On Mon, 6 Apr 2009 10:02:41 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish).
It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh.
Won't help ;)
Namcap is a supported script by the way.
I figured in the meantime :)
Does one know how to report bugs for namcap?
Arch Linux bug tracker: http://bugs.archlinux.org/index.php?project=1&do=index&switch=1
Already reported: http://bugs.archlinux.org/task/14124?opened=4326 Does the AUR webpage and yaourt rely on namcap as well? Both don't get it right either. '+' bug for yaourt reported here: http://bugs.archlinux.org/task/14122?opened=4326 Best regards, Philipp
On Mon, Apr 06, 2009 at 04:21:53PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 10:02:41 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish).
It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh.
Won't help ;)
What do you suggest? I could delete and/or block yaourt from AUR if there are too many support requests to Arch.
Does the AUR webpage and yaourt rely on namcap as well? Both don't get it right either.
AUR doesn't rely on namcap.
'+' bug for yaourt reported here: http://bugs.archlinux.org/task/14122?opened=4326
Jeez don't file bugs for unsupported scripts. Contact the yaourt developers. If you can't get a hold of them then there's nothing that the Arch Linux devs can do for you.
On Mon, 6 Apr 2009 10:27:21 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 04:21:53PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 10:02:41 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollunder@gmx.at wrote:
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollunder@gmx.at wrote:
So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers..
When tracking down bugs please do not pollute your results by relying on unsupported scripts.
The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish).
It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh.
Won't help ;)
What do you suggest? I could delete and/or block yaourt from AUR if there are too many support requests to Arch.
I don't suggest anything, just point out reality. Almost every Arch user uses AUR, many through yaourt. yaourt, Votes: 1918, certainly far more users than that. It still is in AUR, not community.
Does the AUR webpage and yaourt rely on namcap as well? Both don't get it right either.
AUR doesn't rely on namcap.
K, thanks, so I have to file another one, hopefully at the right place for a change.
'+' bug for yaourt reported here: http://bugs.archlinux.org/task/14122?opened=4326
Jeez don't file bugs for unsupported scripts. Contact the yaourt developers. If you can't get a hold of them then there's nothing that the Arch Linux devs can do for you.
For me the case is simple, the yaourt webpage[1] led me to this bugtracker or at least made it appeared to be the bugtracker, I just reported the bug. If this is wrong then official Arch and yaourt need to straighten this out. No matter if it's unofficial, it's heavily related and as such both projects should talk to each other. [1] http://archlinux.fr/yaourt-en Best regards, Philipp
Le Mon, 6 Apr 2009 16:53:16 +0200, <hollunder@gmx.at> a écrit :
For me the case is simple, the yaourt webpage[1] led me to this bugtracker or at least made it appeared to be the bugtracker, I just reported the bug. If this is wrong then official Arch and yaourt need to straighten this out. No matter if it's unofficial, it's heavily related and as such both projects should talk to each other.
The real bugtracker for Yaourt is the one linked at the bottom of the page, not at its top [1]. The people at archlinux.fr should indeed fix that so that no more users report bugs for Yaourt on the official bugtracker. [1] http://bugs.archlinux.fr/index.php?tasks=all&project=3&string=&type=&sev=&due=&dev=&cat=&status=all&date=0 -- catwell
To my knowledge, this is a namcap limitation (I've never used yaourt before). As to why I've never filed a bug - I don't think it's that much of a big issue. namcap is a complementary packaging tool; it isn't fool-proof. It's supposed to be a secondary aid - the first is your judgement from careful practice. Fixing the "+" problem in AUR won't be of much help IMHO (but I recall it was in the TODO list). Such a package can come with "p" instead, and when/if it gets to a supported repository there'd be nothing to complain about.
On Tue, 7 Apr 2009 05:16:53 +0800 Ray Rashif <schivmeister@gmail.com> wrote:
To my knowledge, this is a namcap limitation (I've never used yaourt before). As to why I've never filed a bug - I don't think it's that much of a big issue. namcap is a complementary packaging tool; it isn't fool-proof. It's supposed to be a secondary aid - the first is your judgement from careful practice.
Fixing the "+" problem in AUR won't be of much help IMHO (but I recall it was in the TODO list). Such a package can come with "p" instead, and when/if it gets to a supported repository there'd be nothing to complain about.
namcap, AUR and yaourt have that limitation, I filed feature requests for all three as well as a bugreport for the + issue in yaourt. I agree that namcap is just a tool but quite an important one, it's _the_ dependency checking tool for arch, even if it doesn't work for everything. It should handle these not too common cases that it can handle correctly, or rather expose the same behaviour as pacman. Yes, you still need to get the package to compile first and test the functionality, but I couldn't package effectively without it.
Le Tue, 7 Apr 2009 05:16:53 +0800, Ray Rashif <schivmeister@gmail.com> a écrit :
Fixing the "+" problem in AUR won't be of much help IMHO (but I recall it was in the TODO list). Such a package can come with "p" instead, and when/if it gets to a supported repository there'd be nothing to complain about.
It could be a problem for packages in community, which are both in AUR and in a repository.
I haven't checked up on its progress but there was a discussion about getting community to share the table w/ core and extra. That would solve it. If not, I don't see how "cpp" hurts more than "c++" as they're generally accepted to be interchangeable. On 06/04/2009, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Tue, 7 Apr 2009 05:16:53 +0800, Ray Rashif <schivmeister@gmail.com> a écrit :
Fixing the "+" problem in AUR won't be of much help IMHO (but I recall it was in the TODO list). Such a package can come with "p" instead, and when/if it gets to a supported repository there'd be nothing to complain about.
It could be a problem for packages in community, which are both in AUR and in a repository.
participants (8)
-
Abhishek Dasgupta
-
Allan McRae
-
Daenyth Blank
-
hollunder＠gmx.at
-
Laurie Clark-Michalek
-
Loui Chang
-
Pierre Chapuis
-
Ray Rashif