The gnome-base/ORBit ebuild fails to respect the USE="tpcd" flag. I checked this with the ebuild version ORBit-0.5.17, which appears to be the latest. The package depends on tcp-wrappers regardless of the flag. I tested the source and the configure script perfectly detects whether or not to build with tcp-wrappers support. It's not even worth attaching a new ebuild, just change: >=sys-apps/tcp-wrappers-7.6 to tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) Thank you!
That sort of change works only for dependencies, not for the build. Consider this : implement change suggested. have tcp-wrappers installed, but USE="-tcpd" What will happen? Why will orbit suddenly break when I remove tcp-wrappers, or when I install the binary ORBit?
The problem right now is that there are a bunch of packages that do not respect the tcpd USE flag. Fixing just this one is not going to solve the problem; if someone has unmerged tcp-wrappers it will just appear again with the next emerge -uUD world. I have submitted fixes for a number of ebuilds and until they are all fixed, no one is going to be able to unmerge tcp-wrappers completely safely (although most binaries continue to function perfectly without it). The best we can do now, is remove the false dependency (for those with -tcpd) and hope that in the future this corrects itself. Yes, if tcp-wrappers is still installed, ORBit will still compile with tcp-wrapper support. This is a mess because people did not write their ebuilds right in the first place, not because we are correcting them now.
This will go into the pile of several reasons. a) to enable a tcpd? () check its not enough to just change DEPEND and hope it goes away. Actual linking has to match USE flags. So if a user has USE="-tcpd" it may not link to tcp-wrappers, or it will break the dependency-tracking. b) Disabling this reliably requires fairly major changes to the configure scripts and logic, patching this for an old, stable and deprecated (gnome 1.4 ) package is unnecessary overhead and maintainance issue. c) Disabling tcp-wrappers in ORBit will make it fail if it tries to use IP for transport, and will break well documented and required functionality in the package. Doing this with custom patches just to add the choice is unnecessary overhead and induce prone breakage.
Your last comment is completely preposterous. You simply cannot _force_ tcp-wrappers to be installed on a base library like ORBit. Anyone who wants gnome extensions in their GTK apps, is going to enable +gnome and therefore ORBit will be installed. You cannot force them to also install tcp-wrappers when it is a clearly defined USE variable. You simply must make this change and change the configure script at a later date. I agree that this is a matter for the ORBit development team, but that doesn't mean you must require tcp-wrappers to be installed at this time. If you think tcp-wrappers is so integral, why don't you petition for the USE flag to be removed?
This is still a bug. If my ebuild submission isn't the right way to do it, you should leave this open until it's fixed with something better.
Wontfix until you come up with a better patch. And btw. to clarify a thing you don't seem to have grasped: USE flags aren't A and O at all times. USE="-X -gtk -gnome" emerge gnome, will still give you gtk X and Gnome, no amount of whining will change that. In this case, the package will fail to operate reliably (reliably. in this case random dependencies isn't "reliably" ) if this is changed.
To clarify once more, the problem is that the orbit configure script does not support switching tcpd on or off hardcoded. So either (1) we hack it in so it can be forced one way or the other (which we dont think is worth the effort in this case) or (2) we have it on by default, we go for 2 atm. It seems to us pretty reasonable functionality to have working IP support by default, so it's not a big problem to us to leave it on. To some extent if one wants to hack out tcp-wrap support all the way for some reason, we assume they can do it by themselves. A patch (see 1) would be welcome though as spider stated. If there's a bug closed and you have a problem with that/don't understand why, it's usually better to try and reach the dev via IRC or second option email. We usually have a pretty good reason to close something, but it may not always be clear enough in the closing comment what we mean. A little conversation might be enlightening.
*** Bug 40000 has been marked as a duplicate of this bug. ***
Please take a look at Bug 34016 (the last 2 comments) and let me know if this is an acceptable solution to this problem. I have spent a great deal of time dealing with this issue, and would appreciate some support. This trend of forcing dependencies appears also in Bug 44112. Clearly, Gentoo users would like a better solution than just "WONTFIX". Thank you!
unortunately that is not a valid solution either as it doesn't solve this. There have been repeated attempts to special-case this but none provide reliability. The "fix" suggested is to break it further for the pleasure of less care on your behalf. I don't think that is a working solution myself, and unless you can explain in great detail the benefits of breaking things, this will stay a WONTFIX issue.
I do not understand why the ewarn fix is acceptable to one maintainer (Mamoru KOMACHI <usata@gentoo.org>, Bug 34016), implemented by 2 others (Robin Johnson <robbat2@gentoo.org> and MATSUU Takuto <matsuu@gentoo.org>, Bug 29079), yet considered to be self-indulgent carelessness on my part by you. As for your security concern, a truly security-conscious administrator would be using netfilter to secure a daemon rather than tcp-wrappers.
leave me out of this, please, I'm not even part of gentoo
no, a real security-conscious administrator would use all means at his available to secure his systems. In my work network that's a fully transparent OpenBSD firewall, netfilter on each machine AND tcp-wrappers. netfilter isn't a good fix on it's own for RPC based services as their effective port numbers can and do change (eg load-spreading NFS over multiple ports).
There are two sides to everything. In the past, tcp-wrappers has been exploitable itself(1). Therefore using tcp-wrappers actually would have increased the security concerns. I'm sure in the future netfilter or ipfilter will have some kind of vulnerability. The questions is, how many pieces of software do you want to maintain. Simple is sometimes better. In addition, there is now a module for iptables that filters RPC services accurately. Ref (1): http://www.securityfocus.com/advisories/1359 http://www.securityfocus.com/advisories/3515 http://www.securityfocus.com/advisories/333
I just committed a patch for configure.in to make use of --disable-tcpd option for app-text/dgs. I don't want to take "ewarn" workaround for granted, as we (text-markup herd) knew it wasn't a good solution and was just a temporal reminder for users benefit (if there isn't a patch for --disable-tcpd you cannot remove the dependency, as you noted). I second Spider and foser's opinion here. Definitely we need patches for each package to fix "tcpd" USE flag issue.
I, too, agree that we need patches to properly enable and disable tcp-wrappers support for this package and some of the others I've mentioned. I have never disagreed on this point. This is not, however, the issue at hand. We do not have patches for this issue. For 5 months, no one has been able to provide them. I freely admit that I am unable to provide patches, because I am not familiar enough with automake scripting. I have searched dozens of packages and have found no concise detection method for tcp-wrappers. In the meantime, I believe it has been demonstrated in this bug that there are both pros and cons to using tcp-wrappers. My primary concern is to give users the choice to use tcp-wrappers or not. With a hard dependency in this ebuild, the users have no choice. I disagree that we should leave this ebuild as-is.
I believe you have demonstrated here that you have never carefuly read the comments in this bug. We do not disagree on the issue that it would be better, but we clearly said we won't put the time in to fix an ancient package used by less and less people (i very much doubt it gets installed on a base system). If you want to have it fixed you have to come up with a patch. Waiting 5 months won't change that, nor will adding some other random devs on CC (have they given their permission to do so? i consider that sort of stuff spam). The users who care enough about removing tcp-wrappers from their system completely (i doubt there are many) certainly will have no trouble getting around this package.
Not once in this bug was it mentioned that this package is obsolete. Previous to your last post, I was using gnome-libs: # USE_ORDER="default" emerge -pv gnome-libs These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] media-sound/esound-0.2.33 -alsa -ipv6 -tcpd 339 kB [ebuild N ] sys-apps/tcp-wrappers-7.6-r8 -ipv6 -static 115 kB [ebuild N ] gnome-base/ORBit-0.5.17 -nls 1,040 kB [ebuild N ] gnome-base/gnome-libs-1.4.2 -doc -kde -nls 2,807 kB As you can see, I have no choice but to install ORBit and tcp-wrappers. Should I not be using gnome-libs? The ebuild has been updated as recently as yesterday. I noticed libgnome existed and made use of ORBit2. Is this what I should be using? There are no comments in any of the ebuilds or ChangeLogs letting me know this.
Cory, From what can see your hot on this topic. I sorta can't blame you. I also can understand what appears to be your frustration. How about something like this.. You go read the autoconf manuals etc.. whatever.. Become a guru on the subject. Work with the upstream authors (the guys who actually write said code).. When all is said and done. Come back and lets revisit the bugs when the -tcpd solution will work across the board. My two bits on the best way to get results.
this code is _not_ maintained anymore... hasn't been for a long time. A casual user will not have to install 'gnome-libs' anymore. gtk/gnome1 and anything related is considered legacy by upstream authors and us likewise. And no, I don't understand his frustration. This is easy to 'fix' on a local level -if it bothers cory so much-, but gentoo wide we can't use hacks and we just need a commitment (a working patch) that he obviously isn't willing to make. So cory just keeps reopening this bug and dragging people into it in hopes of getting his will done -i assume this, but thats what i get from it- : that is frustrating. In short, in the light of all the other work we have to do, this is such a non-issue that we won't put the time in. We're working on a priority based model here and this just has no priority at all.
Thank you for the reply solar, I appreciate your sympathy. Foser, Spider, in the future, telling me that the package is obsolete should probably be the first thing you do, not the last. This has wasted an enormous amount of a lot of people's time, and could have been avoided. I re-opened the bug several months ago, because you closed it for no reason. I have not reopened it since then. In any case, I agree that the bug is completely closed.
If you say so you never really read our replies.. i think comment #3 point b is quite clear on the 'obsolete' matter (besides the other points why this is a waste of developer time). And those 3 points are the reasons why it got closed in the first place, so your claim that we closed it 'without reason' is bizarro world type of reasoning. And we always were open to a patch from the users side (comment #7), but i never saw one or any effort to create one. Don't try to blame us for the things you want in for yourself, you get to do the job.
