Re: [gentoo-user] local overlay problem
Am 01.02.2013 03:41, schrieb Philip Webb: Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound; this is still the case with USE=-alsa. I want to test what happens if I try to compile it without that dep, so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ commented the relevant line to remove the RDEPEND. When I then tried 'ebuild newpkgname...ebuild manifest', it started to download xillions of little .xpi files into distfiles , apparently 1 for each of the World's many languages (this didn't happen at my last 'eix-sync'). What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :)
Re: [gentoo-user] local overlay problem
On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote: What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :) Because every emerge @world will want to install ALSA. You may find it will not compile without alsa-lib being present, you could try moving the dep from RDEPEND to DEPEND, then you can remove alsa-lib once the emerge has completed. BTW, /var/lib/layman is for layman-managed overlays, local overlays are best kept separate. -- Neil Bothwick Don't count the days, make the days count. signature.asc Description: PGP signature
Re: [gentoo-user] local overlay problem
Neil Bothwick wrote: On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote: What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :) Because every emerge @world will want to install ALSA. SNIP Don't add it to the world file then, just upgrade it manually each time. Maybe at some point, there will be a way to install it the way the OP wants it, no sound. I wonder if a bug report would help on this? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] local overlay problem
On Fri, 01 Feb 2013 04:42:38 -0600, Dale wrote: What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :) Because every emerge @world will want to install ALSA. Don't add it to the world file then, just upgrade it manually each time. Then portage will want to depclean it. It is always best to try to use the methods portage provides instead of trying to be clever than it. -- Neil Bothwick Did you know that eskimos have 17 different words for linguist? signature.asc Description: PGP signature
Re: [gentoo-user] local overlay problem
Neil Bothwick wrote: On Fri, 01 Feb 2013 04:42:38 -0600, Dale wrote: What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :) Because every emerge @world will want to install ALSA. Don't add it to the world file then, just upgrade it manually each time. Then portage will want to depclean it. It is always best to try to use the methods portage provides instead of trying to be clever than it. When you start working AROUND portage with one thing, then you have to work AROUND portage with a lot of things. This would include depclean. Run depclean with -p and remove packages manually. If that is to much trouble, let depclean remove it and just emerge -k the package again after depclean is done. I'm not saying either of us is wrong, I'm just saying that when you try to override portage, you have to deal with the issues that creates. Either way will work but nether way is going to be easy in the long run. Either way, portage is going to want to fix whatever it thinks is broken, even if it is not. Every time there is a update, time to fix the ebuild again. Pick a poison and swallow hard. lol I think the best way is to talk to the dev that maintains it and find out of he can make sound a option. If a person does not have a system capable of sound, why have it built in anyway. I can certainly see that as I have had systems in the past that had no sound. Then again, there is the mute option. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] local overlay problem
2013/2/1 Neil Bothwick n...@digimed.co.uk On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote: What about not using the local overlay and simply do emerge --nodeps firefox and see what happens? I know, crude but simple :) Because every emerge @world will want to install ALSA. You may find it will not compile without alsa-lib being present, you could try moving the dep from RDEPEND to DEPEND, then you can remove alsa-lib once the emerge has completed. BTW, /var/lib/layman is for layman-managed overlays, local overlays are best kept separate. I understand that, but Philip wrote that he wanted to find out if he could compile ff without alsa-lib beeing present. To just test this case, emerge --nodeps ff is perfect. If he finds out that ff would infact compile without alsa-lib, he could open a bug rebort at b.g.o to make alsa-lib optional. (or for that matter, create a patched ebuild in his local overlay)
Re: [gentoo-user] local overlay problem
On Fri, 01 Feb 2013 05:35:06 -0600, Dale wrote: Don't add it to the world file then, just upgrade it manually each time. Then portage will want to depclean it. It is always best to try to use the methods portage provides instead of trying to be clever than it. When you start working AROUND portage with one thing, then you have to work AROUND portage with a lot of things. This would include depclean. Which is why I think you shouldn't try to work around portage. It provides a clean way of doing this, overlays, use them. -- Neil Bothwick The sooner you fall behind the more time you'll have to catch up. signature.asc Description: PGP signature
Re: [gentoo-user] local overlay problem
Neil Bothwick wrote: On Fri, 01 Feb 2013 05:35:06 -0600, Dale wrote: Don't add it to the world file then, just upgrade it manually each time. Then portage will want to depclean it. It is always best to try to use the methods portage provides instead of trying to be clever than it. When you start working AROUND portage with one thing, then you have to work AROUND portage with a lot of things. This would include depclean. Which is why I think you shouldn't try to work around portage. It provides a clean way of doing this, overlays, use them. Then you have to update those too. As I said, either way in the long term, you have to work at overriding portage defaults. Both ways will give the same result, both ways require work. The best thing is what I mentioned and someone else mentioned, talk to the dev and ask if it can be a option instead of a requirement. That would fix the whole thing maybe even for others too. Lots of options. OP just needs to pick whatever will work for him. After all, it will be him working on this not us. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] local overlay problem
On Fri, 01 Feb 2013 06:59:43 -0600, Dale wrote: work AROUND portage with a lot of things. This would include depclean. Which is why I think you shouldn't try to work around portage. It provides a clean way of doing this, overlays, use them. Then you have to update those too. As I said, either way in the long term, you have to work at overriding portage defaults. But an overlay is working with portage, the other options are trying to trick it. Both ways will give the same result, both ways require work. The best thing is what I mentioned and someone else mentioned, talk to the dev and ask if it can be a option instead of a requirement. That would fix the whole thing maybe even for others too. Agreed, we don't even know if it is possible to compile Firefox without alsa-lib. However, devs help those who help themselves, providing a modified ebuild that works, even partially, is more likely to get a resolution in the tree. The other option is to file a bug. Why is alsa in IUSE if the ebuild depends on alsa-lib either way? -- Neil Bothwick We can sympathize with a child who is afraid of the dark, but the tragedy of life is that most people are afraid of the light. signature.asc Description: PGP signature
Re: [gentoo-user] local overlay problem
Neil Bothwick wrote: On Fri, 01 Feb 2013 06:59:43 -0600, Dale wrote: work AROUND portage with a lot of things. This would include depclean. Which is why I think you shouldn't try to work around portage. It provides a clean way of doing this, overlays, use them. Then you have to update those too. As I said, either way in the long term, you have to work at overriding portage defaults. But an overlay is working with portage, the other options are trying to trick it. I'm not saying it is. I'm saying that the OP would then have to maintain the overlay which requires work. Depending on his skills, he may not REALLY want to do that. Both ways will give the same result, both ways require work. The best thing is what I mentioned and someone else mentioned, talk to the dev and ask if it can be a option instead of a requirement. That would fix the whole thing maybe even for others too. Agreed, we don't even know if it is possible to compile Firefox without alsa-lib. However, devs help those who help themselves, providing a modified ebuild that works, even partially, is more likely to get a resolution in the tree. The other option is to file a bug. Why is alsa in IUSE if the ebuild depends on alsa-lib either way? That's what I would do too. Why does Firefox really need sound to compile? I go to a LOT of sites that don't use sound and even those that do need it, I generally keep things muted anyway. I hate clicking on a link in a email so that it can load while I read another email then all of a sudden my speakers start blasting at a fire truck siren volume level. Then I have to switch desktops, figure out which tab it is that has the sound. Muting is always best for me. I hate autoplay too. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] local overlay problem
On Fri, 01 Feb 2013 07:32:24 -0600, Dale wrote: Then you have to update those too. As I said, either way in the long term, you have to work at overriding portage defaults. But an overlay is working with portage, the other options are trying to trick it. I'm not saying it is. I'm saying that the OP would then have to maintain the overlay which requires work. Depending on his skills, he may not REALLY want to do that. He may not need to. Once he gets it working with a proper -alsa, he can file a bug report with the fixed ebuild, which could then make it into the tree. Or he may find that compiling without alsa is no feasible, in which case the tree could still be changed, to remove the +alsa from IUSE. Either way, trying to lie to portage or prevent it doing what it wants is generally a bad idea. -- Neil Bothwick Why do kamikaze pilots wear helmets? signature.asc Description: PGP signature
Re: [gentoo-user] local overlay problem
130201 Michael Hampicke wrote: What about not using the local overlay and simply do 'emerge --nodeps firefox' and see what happens? Philip wants to find out if he can compile FF without alsa-lib. To just test this case, 'emerge --nodeps ff' is perfect. If he finds out that ff would infact compile without alsa-lib, he could open a bug rebort at b.g.o to make alsa-lib optional or for that matter, create a patched ebuild in his local overlay. I did submit Bug 454330 with the result you can see : it looks as if the real problem is upstream that the Gentoo developer had a hard time getting FF 17 to stabilise. I am not satisfied, but need to offer some effort of my own before I can reasonably re-open the bug or submit a bug to FF itself. I do feel very strongly that Gentoo should not force sound on anyone that the issue is basic, not some personal preference. KDE requires a hook for sound, but not sound software itself, so users can compile 'USE=gstreamer --nodeps media-sound/phonon', after which Kdelibs will emerge successfully. That's what's needed for Firefox. Thanks for all the replies : I will explore further report back. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] local overlay problem
Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound; this is still the case with USE=-alsa. I want to test what happens if I try to compile it without that dep, so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ commented the relevant line to remove the RDEPEND. When I then tried 'ebuild newpkgname...ebuild manifest', it started to download xillions of little .xpi files into distfiles , apparently 1 for each of the World's many languages (this didn't happen at my last 'eix-sync'). Can anyone suggest a way to avoid this problem ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] local overlay problem
On 1/31/2013 20:41, Philip Webb wrote: Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound; this is still the case with USE=-alsa. I want to test what happens if I try to compile it without that dep, so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ commented the relevant line to remove the RDEPEND. When I then tried 'ebuild newpkgname...ebuild manifest', it started to download xillions of little .xpi files into distfiles , apparently 1 for each of the World's many languages (this didn't happen at my last 'eix-sync'). Can anyone suggest a way to avoid this problem ? It's downloading those files so it can recalculate the file hashes. When running `ebuild file digest`, it has to have all possible files available in order to update the Manifest file. Those languages won't be installed when you actually install your modified package. You'll probably want to keep them around until you're finished making changes, though. -- ♫Dustin
Re: [gentoo-user] local overlay problem
130131 Dustin C. Hatch wrote: On 1/31/2013 20:41, Philip Webb wrote: Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound; this is still the case with USE=-alsa. I want to test what happens if I try to compile it without that dep, so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ commented the relevant line to remove the RDEPEND. When I then tried 'ebuild newpkgname...ebuild manifest', it started to download xillions of little .xpi files into distfiles , apparently 1 for each of the World's many languages (this didn't happen at my last 'eix-sync'). It's downloading those files so it can recalculate the file hashes. That's what I suspected (smile). When running `ebuild file digest`, it has to have all possible files available in order to update the Manifest file. Those languages won't be installed when you actually install your modified package. You'll probably want to keep them around until you're finished making changes, though. Why doesn't this happen when I do my weekly 'eix-sync' ? Perhaps it silently downloads them, then deletes them again, or perhaps it simply downloads the Manifest on those occasions, but has to calculate it specially for the non-Portage overlay. I'll give it another try, but suggestions are still welcome. Thanks for this one. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] local overlay problem
On 31/01/13 at 11:38pm, Philip Webb wrote: I'll give it another try, but suggestions are still welcome. Thanks for this one. Maybe you can try adding alsa-lib to package.provided and see if it builds/works? -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] local overlay problem
On Thu, 31 Jan 2013 23:38:27 -0500 Philip Webb purs...@ca.inter.net wrote: When running `ebuild file digest`, it has to have all possible files available in order to update the Manifest file. Those languages won't be installed when you actually install your modified package. You'll probably want to keep them around until you're finished making changes, though. Why doesn't this happen when I do my weekly 'eix-sync' ? Perhaps it silently downloads them, then deletes them again, or perhaps it simply downloads the Manifest on those occasions, but has to calculate it specially for the non-Portage overlay. The Manifest was already calculated by the dev for all those little files in the original, so portage didn't need to redo it. The only file you changed is the ebuild itself. So copy the manifest over from the original, delete the line for the ebuild and run digest again. -- Alan McKinnon alan.mckin...@gmail.com
