yamato ~ # LD_PRELOAD="libperl.so" ./test-zlib /usr/share/squeezecenter/CPAN/arch/5.8.8/i686-linux/auto/Compress/Zlib/Zlib.so zlib version in /usr/share/squeezecenter/CPAN/arch/5.8.8/i686-linux/auto/Compress/Zlib/Zlib.so: 1.2.3 Having a local copy of the modules is bad enough on its own anyway, but why in /usr/share that should only contain arch-independent stuff?
In the 7.3.0 ebuild, very soon to be checked into the tree, the arch files live under /usr/lib/squeezecenter. They should not have been installed under /usr/share.
Diego, the bundling is not ideal, but this package is tricky. There was no other obvious way to make it work well. We do plan to keep migrating it away from the bundling...
Even worse! The YAML-Syck copy in here is also having the same problem as bug #253277.
Stuart, Any chance we can play with chipping away at this, e.g. for YAML/syck and zlib? If we can specify the needed versions in the ebuild it should work, in theory. -Thanks, Joe
I'll certainly take a look at those two; there are a couple of risks with that as I can see it, though: 1. dev-perl/YAML-Syck has no versions marked as stable in the tree, meaning some ~x86 or similar keywording for users. That's not much of a problem for unstable versions of our package, but it will make stabilisation of SqueezeCenter more difficult in future. 2. Both zlib and YAML-Syck versions in portage are significantly newer than those bundled with SqueezeCenter. There might be no problem with that, but there may also be incompatibilities. I should think I can test whether those newer versions work, but it may cause me more patching work and introduce bugs from incompatibilities of those versions. The second one worries me more than the first, but I'll take a look for those two and see if there's any real problem with doing this for those. I had half-convinced myself that the bundled versions wouldn't be a problem since they're effectively internal to SqueezeCenter (they're not installed in the system paths, and wouldn't worry anyone except that they have the names of recognised packages), and it was more a matter of purity whether there were duplicate packages installed. I can appreciate the security/efficiency argument against that, though. Anyway, I'll take a look and note back here.
Yes, I've gone back and forth in my mind on this as well. Diego must brought up other reasons it si suboptimal to have bundled libs. Those 2 iessues you point out are very valid. Also, I am more curious not what other distros su (like Fedora or Ubuntu). If they use bundled internal libs, I'm included to do it that way. If they don't, it strengthens the argument to unbundle. Diego - any comments?
Using internal libs is against our general policy that has been established quite a long time ago; sincerely, this package as it is should never have entered portage in the first place, and it's far from stable material as it is (so the fact that some packages are only ~arch for now shouldn't matter). Debian's policy, and as far as I know Fedora's too, is also to not use internal libraries, for similar reasons than ours. Beside the fact that Perl modules shouldn't change API, for what I know, and that ABI is of relative importance, if changing a version breaks this package, then the package is not good enough to stay in the tree. What should any other package in the tree do when its deps are updated? I really can't see any particular reason why this package needs any special handling than other packages don't.
I'm not sure why you say this package is far from stable. It is the officially released software from upstream. It replaces the previous "slimserver" package that is stale now. If Debian's and Fedora's policies are similar, then we should be able to use them as an example, and we'll investigate.
I mean that from a QA standpoint you cannot deem stable a package that bundles a bunch of crap (internal libraries). Sincerely if I was to give my opinion, as I said, it should NOT have entered portage at all. That the software "works" is not the only requirement for something to go stable, going against policy is a good reason to keep a software from stable. The fact that we currently have lots of packages breaching policy stable, and even more that are not stable but in portage, is not a good reason to increase the number, but rather a good reason to keep it down as much as possible.
I believe I have resolved this in the 7.3.1 ebuild that I'm just submitting. This still includes a number of packaged CPAN modules, but none that are in the standard Portage tree, which should address the original issue of multiple module installations. Additional Perl packages could be added for the residual ones not yet covered, but I think that can be addressed in slower time.
Uhm not his bug is still a bug as long as it bundles Perl modules, whether they are in portage or not; if they are not in portage right now, make this bug depend on bugs to request them to be added, so that we can track them down.
(In reply to comment #11) > Uhm not his bug is still a bug as long as it bundles Perl modules, whether they > are in portage or not; if they are not in portage right now, make this bug > depend on bugs to request them to be added, so that we can track them down. > Will do. I'll raise enhancement bugs for the required modules and make this one depend on them. Thanks for the pointer.
So are we going to do anything about this?
(In reply to comment #13) > So are we going to do anything about this? Yes - I've been meaning to get around to this but clearly haven't so far. I'll start creating those request bugs and making this one depend on them as mentioned in comment#11. Sorry it's taking so long.
I've just submitted the ebuild of squeezeboxserver-7.4.2 to Joe for checking and, hopefully, inclusion in Portage soon. That should address all of the bundled CPAN modules covered by the dependent bugs except for bug#287857, which is waiting for an ebuild of EV.
regarding bug 287857: dev-perl/EV is in Portage now, and my shallow test shows this app works with it, so I suggest to: - remove bundled EV from media-sound/squeezeboxserver, - add dev-perl/EV to dependencies. By the way it should fix a nasty issue: if media-sound/squeezeboxserver has been compiled with Perl 5.a.X and it's run on 5.a.Y, it couldn't find the EV module, because this bundled module is in a custom location that contains 5.a.X, but /usr/lib/perl5/vendor_perl/5.*/Slim/bootstrap.pm prepends a path with 5.a.Y to @INC. See bootstrap.pm, lines 130-140.
New media-sound/logitechmediaserver-bin has been added, which is a binary package, resolving these issues.
Wait, define "binary". Because if it's a prebuilt version that still bundles everything, it's just as broken as before, you're just pretending to hide it under the rug!
(In reply to comment #18) > Wait, define "binary". Because if it's a prebuilt version that still bundles > everything, it's just as broken as before, you're just pretending to hide it > under the rug! Yes, it is the prebuilt version as-is from upstream, with all binaries built. It does the same bundling, yes. This package has always been a particular challenge because of the way upstream packages it. It is very fragile, and although we have gone to great lengths to deconstruct it and make it more Gentoo-like (and I do agree this is desirable), it has gotten to the point at which doing so has caused us (well, Stuart, really, who has contributed a huge amount of work to this) to be unable to keep the releases timely. It became more and more apparent that punting this and doing it as a -bin is more practical (see discussion in this bug: https://bugs.gentoo.org/show_bug.cgi?id=377825). No one is "sweeping this under a rug". There is no denying that there is bundling, but it seems a lot more appropriate to do such in a binary install than in a regular source install. An alternative is to remove it from the tree, but this is a package that is quite in-demand. Squeezebox users have been clamoring for an update to the new version (which takes on a new name as well) for some time, and it has been hard to keep disappointing with very late releases due to the deconstruction of this fragile package.
So this bug stays OPEN until you can stop the bundling or you get rid of it from Portage. In either binary or source bundling is simply bad.
OK, let me address Diego's points about policy: A policy defines a general practice. There are always exceptions to policy. This, unfortunately, is one of them. There are a couple of good reasons for this exception. 1. Logitech is not doing a proper source release that we can work from. If you look at some of the other bugs related to this, you'll see that Logitech DID NOT RELEASE SOURCE for one of the required perl modules. So we have the option of trying to find something in their SVN and get it to build, or do this binary. It's a lot of work to support their media server when they aren't making a source build easy for us. 2. The source builds are a maintenance liability. We end up adding lots of Perl stuff to the Portage tree JUST to support Logitech Media Server. It takes a LOT of time. Gentoo historically has not been able to keep up with the latest releases of the media server which are needed for firmware updates of the players. This is a sub-optimal situation. So Diego, my stance is -- if YOU want to personally maintain the Logitech Media Server (from source) ebuild, and keep it up-to-date (which is a ton of work), so that Gentoo can be used with the SqueezeBox, that would be awesome. But if that is not the case (and I don't think it is, is it?) then the Logitech Media Server (from source) ebuild is basically dead, so pushing back on the -bin version is just basically pushing for Gentoo to not support the SqueezeBox at all, which I know users don't want. In other words, "The perfect is the enemy of the good." This is the only feasible way to support SqueezeBox in Gentoo at this time. When someone comes along with the time and patience to personally maintain a source version and keep it up-to-date (which is needed for latest squeezebox firmware), then by all means let's get rid of the -bin. But I don't see that happening any time soon. Also, I would suggest that this person focus on more important things anyway.
This is still a liability, and I'd rather have this under a p.mask saying that we don't security-support systems with this installed (as we shouldn't, full stop).
Sorry, Diego, but I'm with Joe and Stuart (and Daniel) on this one. Having the SqueezeBox server on gentoo is a good thing, and if unbundling is such a PITA that (a) no one is willing to do it or (b) those who have been willing to do it spend so much time on it they can't do reasonably timely updates, a binary package seems like a fairly good solution.
This is not a matter of binary or source. This is a matter of "if you add a package that bundles the world, you're making yourself vulnerable to the world's security issues". Call it however you want but this is a bad move in general. You want to keep it in tree? Fine. But keep this bug open because it's going to tell us that it _is_ bundling the world, and that also means that if a vulnerability is found you have to follow through with it. The fact that something's difficult to do right is not a license to do it wrong because people want it anyway, at least in Gentoo.
Diego, This started as an argument about bundling, which I understand, but in this case there seems to be no other practical way (see all previous comments about why upstream's distribution is problematic; it is not that this is simply "hard" to do - it is quite more than that). But now you are calling this a security issue. Is it the bundling or the binary nature that makes it so (or both)? I would think if Gentoo called every -bin package a security issue (in the latter case), then -bin packages would not be allowed at all. If it is about the bundling (and I do agree that old bundled versions of modules could have security issues), the bundled pieces are only used by this one package in a self-contained way, so the security issue would only exist if the package's use of a certain version of a bundled package exposed a vulnerability. The same would apply to a -bin package with statically-linked libs (are there any of these in the tree?). Since there is clearly a difference of opinion here among Gentoo devs, how to we get a clear consensus? I know that you personally object to this rather strongly, but that alone does not define it as egregious.
Want to hear what Security has to say? I'm pretty sure they are almost as bothered as me by bundling. What makes it a security issue is definitely the bundling, especially if you consider that you have in front of you a service that is _network-facing_. Can you really not see the connection? I'm not even telling you "don't add it to the tree", what I'm telling you is "don't pretend that sticking a -bin in it makes it fine" and "consider the idea of just package.masking it with a message stating that we can't vouch for its security". And the only thing I'm stating is "don't close this bug just due to a rename".
[First, I hesitate to add more noise to this bug, but I think there is still a disconnect] Certainly, Diego, I see what you are saying regarding a network service's need to be secure. And I know what you are asking for - we'll keep the bug open for now. First, I want to make it very clear, like I said before, that there is *no* intention here of hiding the bundling. That is not the reason for the -bin. And yes, if there is a vulnerability in the package (whether in a bundled component or not), that vulnerability would exist in the upstream release of this package, affecting any users on *any* distro who install upstream's package. We would need to address it the same way we would for any vulnerable package. And yes, *if* we could successfully unbundle and build from source, then we potentially could correct vulnerable components without needing a new upstream release of this whole package, adding value in that case above and beyond what other non-Gentoo users get. But given how fragile this package is as packaged by upstream, this has proven to be very difficult. The main point is that we are not inducing *more* risk to one who wants to use the Logitech server. One is no more vulnerable using this -bin Gentoo package than just installing upstream's bundle directly.
True, but users expect us to provide them with an experience that is _better_ than what comes from upstream. And if we can't promise them any better security _and_ we know the package is tremendously vulnerable, that's not a good thing to provide. So simply put, I only ask you to put it in a simple package.mask (it's easy for an user to unmask it with modern Portage), stating that the package is not supported for security. Seems fair to me.
(In reply to comment #28) > True, but users expect us to provide them with an experience that is > _better_ than what comes from upstream. And if we can't promise them any > better security _and_ we know the package is tremendously vulnerable, that's > not a good thing to provide. I agree a mask is appropriate if a package is "tremendously vulnerable". But what makes you think this one deserves that description? Another option that I think would be reasonable and good is some warning text on installation that this package, as put together by upstream, bundles components due to Logitech's specific dependencies, and that has the potential to pose risks. There's such a caveat on adobe-flash, which has had known vulnerabilities, and that package is not masked. Thoughts?
Security should call it I guess. But even if you don't mask it I don't intend to see it ever reaching "stable". Flash is a mess by itself, and honestly I would just mask it as much as before.
OFFS it also installs PPC files?!? Guys this stuff should have never come within 20' of the tree!
(In reply to comment #31) > OFFS it also installs PPC files?!? Guys this stuff should have never come > within 20' of the tree! Stuart, is it relatively easy to prevent non-applicable architecture files from being installed?
Yes. I'll work up an update to the ebuild. At the risk of starting something I don't really want to get into I can't really see what the problem is as the other arches' code won't attempt to run. There are probably a lot of other data files in there that wouldn't be needed either - eg other locales' strings. > OFFS For my benefit, can someone point me to relevant Ebuild documentation that says this is violating some principle, rather than just style, taste or preference? Presumably the offence is caused by the files in /Bin and /CPAN/arch/*, but it's hard to tell from this rather abrupt comment.
(In reply to comment #33) > > OFFS > > For my benefit, can someone point me to relevant Ebuild documentation that > says this is violating some principle, rather than just style, taste or > preference? Stuart, good question, and yes, I would also like to know.
Diego, your security instincts are endearing but misguided in this particular case. The most secure policy is to keep up-to-date with upstream. -bin packages allow this to happen more easily. Therefore, -bin packages are generally more secure than a difficult-to-maintain source package that is out of date. Here is a real-life example, there was a directory traversal vulnerability in 7.7.1 (http://bugs.slimdevices.com/show_bug.cgi?id=17841) that was addressed in 7.7.2. The bug was not surprisingly in the server code and not in the perl dependencies. So your theoretical security argument does not hold up in practice. And let's not pretend that security is of the utmost importance for this package, as it is run on home networks and used for playing back music. This is hardly a high-risk environment. This service is not intended to be used with a public IP address on the Internet and no one sets it up this way. It meets the relatively low security requirements of a home environment in which it is deployed. Regarding this larger packaging debate, I would wager that Gentoo users are primarily concerned with using their Squeezeboxes with Gentoo rather than following this ongoing multi-year debate on bugs.gentoo.org. I know, it's fun to argue for (literally!) years, but c'mon -- priorities, people. Let's take care of users. If you want to argue, join a debate club, or get a job at Logitech and make this package more distro-friendly. This bug should be closed.
Daniel, luckily for Gentoo users, you don't call the shots anymore, so SHUT YOUR PIEHOLE, thanks. Stuart, it's not like there's a policy against installing other-arches binaries, but generally packages shouldn't install files "just because". And this all thing is keeping on the "It's too hard to do it right so I'll pretend that doing it wrong is fine" line, and that bothers me a whole lot.
Stuart, one thing I noticed -- I think you should reduce the keywords from "~amd64 ~x86" to "amd64 x86" due to the lack of perl-5.16 support from upstream and lack of <5.16 support in gentoo unstable. Because perl is not slotted and gentoo unstable is using perl 5.16, unstable users may not recognize that emerging logitechmediaserver-bin forces a downgrade of perl and hoses various parts of their system in the process. If we had a slotted perl, this wouldn't be an issue, but as of right now, if you are on gentoo unstable and have ithreads set, Portage will happily downgrade perl when you merge logitechmediaserver-bin. Hopefully we will have a perl-5.16 compatible LMS soon :) It looks like the SqueezeBox user community is working on it in the meantime: http://forums.slimdevices.com/showthread.php?96492-opensuse-12-2-fails-to-run-logitechmediaserver-7-8-0-0-1-1347896053 Thanks for your efforts in supporting us SqueezeBox owners. Best Regards, Daniel
(In reply to comment #37) > Stuart, one thing I noticed -- I think you should reduce the keywords from > "~amd64 ~x86" to "amd64 x86" due to the lack of perl-5.16 support from > upstream and lack of <5.16 support in gentoo unstable. You can't be serious. Knowing who you are I can't decide between absolutely clueless and evilness. I expect you to know better. Wrt this bug, I'm on Diego's side. Unbundling is desired at any rate. It's not the end of the world if the goal can't be reached due to lack of manpower and or cooperation from upstream, however, a bug documenting the QA and possible security concerns is more than appropriate. If something endangers this package staying in Gentoo then it's the lack of insight how to handle a package touching gray areas on various occasions and not the fact that it does by itself. @Stuart: thanks for maintaining a difficult package all this time, let's hope someone will pick up where Joe left soon. I don't own the hardware so won't offer my help but suggest to outright ignore drobbins if the ebuild shall stay compatible with Gentoo.
@proxy-maint team, are you will to proxy maintain Stuart for this? (this package is now in maintainer-needed)
Stuart has informed me that he is not following-up on this bug -- seemingly due to a lack of productivity and maturity from Gentoo developers. I will also cease to comment on this bug, for similar reasons. For the future of this ebuild, I will preserve it in Funtoo Linux and try to ensure that viable option for Squeezebox owners exists. I plan to do this with an unmask in Funtoo Linux stable combined with an unstable mask to prevent accidental Perl explosions for unstable users. This will allow Funtoo stable to be used as a Squeezebox server. Thanks to everyone who has attempted to be helpful and I hope even the scrooges (you know who you are) have a wonderful Christmas/holidays.
If he is not interested then there is nothing for us to do here. Also if his is not interested in this package we will either remove it or drop it to maintainer-needed@gentoo.org
(In reply to comment #41) > If he is not interested then there is nothing for us to do here. Also if his > is not interested in this package we will either remove it or drop it to > maintainer-needed@gentoo.org Will CC qa team: is current ebuild ok to be kept in the tree as-is? If not, what should be fixed? Since I don't think maintainer-needed people will spend a lot of time with this, if we need to put a lot of effort on fixing it, I guess we will need to treeclean it if nobody steps up as maintainer
well the package is not broken ( so I am inclined to say , lets keep it ) but it bundled a load of stuff so I think it should be masked like we do with other packages too ( eg avidemux )
(In reply to comment #41) > If he is not interested then there is nothing for us to do here. Also if his > is not interested in this package we will either remove it or drop it to > maintainer-needed@gentoo.org Hello, I've had a discussion with Denis Dupeyron about this package and there have been a couple of developments (I've also seen a recent discussion on gentoo-dev concerning it). We discussed trying to make the package fit more comfortably within the tree but it doesn't seem practical to maintain it in such a way given the significant number of dependencies on specific CPAN module versions. On that basis we thought the best way forward was for it to move into an overlay so that users are consciously aware that they are bringing in an unofficial package and, hopefully, the 'non-standard nature' of it would therefore seem less acute there. Denis has set me up with an overlay and I've created an equivalent version to the latest in-tree version in that overlay. This overlay is now published in Layman. The overlay is called 'squeezebox' and the intention is that this may have a related set of packages concerning this media streaming platform (I've already added a new ebuild for the Squeezelite player): http://gentoo-overlays.zugaina.org/squeezebox I've publicised that overlay within the Squeezebox/Logitech Media Server community (http://forums.slimdevices.com/showthread.php?97562-Gentoo-Logitech-Media-Server-ebuild-moving-to-an-overlay) and so I think people who need to know it's moving to an overlay stand a good chance of having seen that it's happening. In summary, then, I think masking it is a reasonable course of action, and if the masking text can point to the overlay that could help people with the transition. I'm hoping to go through the dev process (working on my quiz now), so I might help maintain some in-tree packages in the future. However, I don't expect this package to move back towards the official tree unless something radical happens. Finally, I appreciate all the input there has been on this. I've tried to make the package as comfortable a fit into the tree as possible, but given its nature that has clearly not been terribly successful.
(In reply to comment #44) > Denis has set me up with an overlay and I've created an equivalent version > to the latest in-tree version in that overlay. This overlay is now published > in Layman. Stuart, this sounds like a fine resolution for this package. Thanks for your efforts in trying to make it fit - yes, it's a challenging one. I am glad a compromise was reached, as it would be too bad to let this package disappear completely. For those with SqueezeBoxes, it's quite an important one. Good luck on your quizzes and on the dev process!
Looks like the best solution, thanks! I guess we should then treeclean this from main tree and point people to your overlay in mask message. Are ebuilds from overlay ready to replace the version in the tree just now?
(In reply to comment #46) > Are ebuilds from overlay ready to replace the version in the tree just now? Yes, I believe they are. I've tested installation of it in my VM and as it's pretty much a straight copy of the most recent in-tree version there's not much chance of unexpected surprises (famous last words!).
Sadly I observed a dangerous development while reading the "discussion" in this bug report. As far as I can tell, Gentoo developers were discussing here how to proceed with a hard to handle package, how to update it, etc. The discussion started in a very focussed manner. Then a Gentoo developer - who does not seem to own a Logitech device and not know that the device must have some software run on a computer in order for it to work at all - is riding the high horse and trying to call the shots because he has a daft idea about Gentoo policy being more important than getting a user's device to work by providing an as-is no-warranties bundle. Once that argument does not fly any more, some other bonkers idea about QA/safety/"Insert you favourite made up reason" is thrown in just because. Obviously the other Gentoo developers who were still(!) trying to figure out a working solution that would make the Logitech devices of the users work, frustratedly give up. Once the developer has joined, the "discussion" comes with amenities like being called names or having arguments ignored. Quiz time: Has anyone of the "devs", especially the guy without a Logitech device, ever considered asking the users who own A Logitech device what they would prefer??? No? Well, I thought so. For the record, here is the opinion of a user who owns such a Logitech device: It is a matter of common sense that in the moment I decide to install binary-only software on my system I become the only responsible person for whatever the software could do to my system in the future. So WTF is this all about? The solution is very simple: after the installation print out a warning about no support, no bug-reports and updates will be provided on an as-available base only and be done with it. As soon as a user files a bug, close it immediately as "Won't fix" because "I told you so". Or is that too complicated? FYI: no one seems to mind that other binary-only packages bundle their own versions of something, e.g. www-client/firefox-bin bundles its own versions of shared libraries. When policy prevails over common sense, I can tell what direction a project is heading for. And obviously it ain't the right one. Signed by a very disappointed user. PS Yes, this comment has been written on purpose with a bit of hot sauce sprayed in for good measure. Any one who feels that she/he should get back to me, is kindly asked to do so by email. I am confident that we can work things out.
Gentoo policy _is_ more important than pleasing one (or a few) user. Please stop trying to have a voice in something you explicitly don't have an idea about.
dropped
(In reply to comment #49) > Gentoo policy _is_ more important than pleasing one (or a few) user. Please > stop trying to have a voice in something you explicitly don't have an idea > about. I almost forgot about this, but your very disrespectful comment merits a response. Yeah, I get it. You don't give a rat's ass about user concerns. Somehow I must have missed your memo about Gentoo now being a distribution for a few chosen people. Here is my advice for you and it is free of charge: son, you ought to mature at some point, it could help your professional development. Then, someday, even you might be regarded to as a professional. Have a nice day, too.
