| Summary: | gnome-base/gdm has screwed-up dependency over sys-auth/pambase[consolekit=] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | freedesktop-bugs, jmbsvicetto, pva |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=461688 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Ebuild patch | ||
|
Description
Diego Elio Pettenò (RETIRED)
2010-11-10 22:20:39 UTC
Created attachment 253923 [details]
Ebuild patch
And this is the bloody stupid CVS patch that leio insisted me in attaching; because just describing "drop the USE flag dependencies on pambase" wasn't verbose enough I guess.
(In reply to comment #0) > (devrel is CCed on this bug since I _am_ going to insult somebody at this > point; freedesktop because it involves consolekit) first of all, please calm down, I'm sure with calm discussion we can come up to a satisfactory situation. > You have botched the consolekit USE flag dependency on gdm. Why? Because the > econf parameter gives you the _internal_ ConsoleKit session-creation support, > and has thus NOTHING to do with PAM, even less with pambase. The dependency is here because we want a coherent setup for the user. If user wants the consolekit support in gdm, then we want users to get it integrated correctly, with the console, ssh sessions, ... That's what the USE flag does on pambase right ? The gnome-keyring is there for the same reason. What's causing you so much trouble that you want us to remove the USE dep ? You are _not_ getting any consistent behaviour right now because gdm, kdm, xdm and slim are all using the _wrong_ service file; login wasn't using it either until a couple of weeks ago. If user wants consistency, they enable consolekit USE flag systemwide and be done with it. Forcing it this way is simply silly (if you want me to calm down; I would have used a different tone tbh). I'm now re-doing the whole pambase package so that it _actually_ works as intended; to actually have that working as intended, though, users most likely should disable the internal consolekit support, otherwise you get two sessions per each gdm login, which is not *bad* but not good either. Finally, let me try to make it more clear: as the only developer too stupid to have left PAM behind me in the past five years, I'm _telling_ (not asking) you to drop those dependencies. They are not right, full stop. You should _not_ condition the user to have the same setup in gdm or the rest of the system anyway. And once the new pambase is in place, you _should_ drop the gnome-keyring USE flag entirely, and simply use the correct stack. But the problem here is deeper: since _I_ am the one that is actually working on the stupid PAM setup, I'd expect cooperation at least in term of "if the PAM maintainer would like something done that given way, the PAM maintainer can do the PAM-limited changes when needed". Otherwise deployment of pambase is going to wait for eternity if I have to wait on bugzilla for _each_ of the packages that have been misusing it up to now. please stop forcing random use flags on random packages. gdm doesn't use pam_ck_connector.so, it works without. it might be the only display manager that doesn't need it :) Diego, (@kde hat) you mentioned kdm on comment #3. Do we need to fix or change anything on kdm? (@devrel hat) Let's see if this issue can be solved in a civil manner between all parties. At least Gilles seems to be interested in addressing this issue. I can't make any comments about Mart as I don't know what's going on between the two of you. Diego approached me on XMPP with "I assume I can fix gdm wrt a screwup in consolekit USE flag?"; I said "not if that's the only information you give", after which he gave a long essay about the technical things while I was unfortunately AFK. As I didn't understand the issue at hand when trying to read it once back, I said that's an essay suitable for bugzilla with a patch attached, as is the normal course of action for a package maintained by someone else; and so that the team members who did the change in the past would also see the information. He wanted to involve devrel from the beginning because he intended to insult me from the start. That's all. WRT KDM; it's also not using pambase properly, but that I'll address when the new pambase is ready, I've already spoken with Thomáš about it (the same goes for XDM; since he's involved with both, I didn't have to explain it twice). Sure I feel like insulting you if you ask me to _attach a patch_ to a bug whose only existence is to explain _why_ you should simply *drop the USE dependency on pambase*. Especially since your original statement wasn't anything related to informing whoever added it but rather this phrase: “uh, now that's an essay that belongs on bugzilla with a patch attachment...”, and you insisting that I cannot simply fix the PAM-related stuff myself (given that I'm pretty sure I know the PAM situation better than most, having been working on it alone for five years now). Your informing-someone-else reason came quite later. The first sentence of the second paragraph of the Developer Relations Policy Guide [1] states: "Developer Relations should only be involved in a conflict when other attempts to solve the issue have failed." So I'm closing RESOLVED LATER until other ways of solving the issues have actually been attempted. Denis. [1] http://www.gentoo.org/proj/en/devrel/policy.xml Denis, I'm already in a foul mood, but I'll try to moderate myself. Closing a _technical_ bug with a devrel resolution is at a minimum telling me you're too busy even reading through it. I wrote this while the bug was moving on, feel free to ignore if it is not relevant: Ok let me try to explain better, we want our users to get the experience consolekit has been designed for, or at the least, the minimum we can give. That is, if someone's on the computer doing stuff, and someone connects via ssh, the remote logged in user cannot halt the machine, or read cdrom, etc. That may be not working this way at the moment, but that's what we want to provide. Any help achieving this is welcome. I know you have master plans about pambase and all, but please don't think you can dictate changes without at least explaining them a bit as I've worked a fair amount of time on making sure ck/gnome-keyring worked correctly in gnome in gentoo when gnome started using it and I don't want that to be broken because users should set the use flag globally. We have no way to express this in gentoo and the best pick we have for now is pambase. Now, if I read between the lines, should we understand that you plan on making login managers symlink their pam files to system-local-login or some such pam config file generated by pambase ? (In reply to comment #10) > Denis, I'm already in a foul mood, but I'll try to moderate myself. Closing a > _technical_ bug with a devrel resolution is at a minimum telling me you're too > busy even reading through it. My bad, I was convinced the bug was assigned to devrel. And for the record, and in case it matters, I'm in a very good mood. Denis. As I said, right now your attempt is utterly failing: - on GDM, you have custom code for gnome-keyring, and the built-in for consolekit; so if you use GNOME with GDM, it's all fine; - on sshd, both works through PAM (although some people complained about having gnome-keyring started up on console, so that you know); - up to a week or two ago, *nothing else worked at all*; - _now_ on login(1), thanks to _Samuli_ who let me know about it, both consolekit and gnome-keyring works just as well as on sshd; - kdm, xdm and slim _don't work_ with either keyring or consolekit; - even if pam was magically fixed in a single commit for those three, slim would still not work because the two of them have different ideas of what rhost is. > Ok let me try to explain better, we want our users to get the experience > consolekit has been designed for, or at the least, the minimum we can give. Congrats, you've failed for a very long time to reach that goals. Why? Because of bad coordination. I'm not saying I haven't had any doing in the failure, but _right now_ I know what to do and how to do it. And one of these steps is for gdm to relent on these dependencies now so that they can be set up properly later. > if someone's on the computer doing stuff, and someone connects via > ssh, the remote logged in user cannot halt the machine, or read cdrom, etc. This should already be the case as long as gdm is used, because if there is no ck session, then ck is not giving authorisation. So far, only a gdm-logged user had those authorisation, now login(1) does as well. As soon as pambase is deployed, XDM and KDM users will have the authorisation as well (Slim as I said will have to wait till the two upstream decide what is the right meaning of rhost). Am I seriously asking you too much to trust me on the PAM-related stuff, so that I can deploy pambase without having to create _bugs with patches_ for every single change? (Do note, I wouldn't have responded so badly if leio told me “Please open a bug so that it's trackable” or “Please open a bug so that the rest of the team is informed”). Oh and Gilles, _you_ regressed it; in the original 2.20.10 the built_with_use checks produced _warnings_ to users that they should change pambase _if they wanted them working_; in -r1 you introduced _hard_ USE dependencies. Which is probably why I didn't ask you not to do that in the first place. Diego, please, read devrel policy and don't CC us without real need. As Denis said first try to resolve issue yourself. Discussion here is quite calm (with exception of you) and technical and I don't think you want devrel's resolution about yourself so I'm removing devrel from CC. But still I'd like to comment on non-technical side here. Maintainer have to know every bit in ebuild. It's hard to expect that maintainer will manage to maintain obscure ebuild's parts, most probable this parts will be amended with next version/revision bump. So if you want PAM related changes to survive maintainer must understand and support this changes. Thus in any case you have to explain reasons behind changes. In Gentoo do not allow to touch ebuilds without contacting maintainer first as 1) this guarantees that maintainer is aware about changes and about reasons for changes and 2) this precludes commit war (in case maintainer disagrees and decides to revert change). So no, you are not allowed to touch packages without maintainers approval. Now communication can be done on any media you want (xmpp,irc,phone) but maintainer is free to ask you file bug. gdm is not maintained by leio alone and thus everybody in gnome team are interested in reasons for this changes and instead of chatting with every gnome member separately it's much faster to open bug report and assign it on gnome team. Also bugzilla serves for documentation purposes and new gnome team members will have chance to find out why these changes were done. And all of this are the reasons why bugzilla is our primary tool for cooperation. Don't take request to open bug report as attack - it's just a fellow suggestion to do things more effectively. From this discussion it's clear that gnome team members spent lot's of time on gdm and thus they have reasons for such dependencies. But this does not mean that dependencies are correct so if you know better I'm sure it's not hard to explain why this changes required. PAM is not a rocket science and everybody here are able to understand how it works. Nobody challenges your PAM knowledge and every developer will listen for your suggestions. But listen does not mean to follow without discussion and in case there are questions maintainer will ask you. Please, help people to understand what's broken and how to fix. With your help developers may take less time to make it working right! Peter I think I have explained three times over why the current situation is wrong I have by now even found why it was introduced in the first place (warnings becoming harddeps without me even being informed); it is one out of a series of steps I have to take for the PAM situation in Gentoo to _start working_ (because as much work as GNOME team can have poured into this, _only GDM worked with ConsoleKit up to last month_) and actually be consistent. I *need* this change applied, as much as I need gdm to start behaving like the other DMs once the new pambase is in place and the deps updated so that old-gdm and new-pambase won't mix in too much (because it will have some limited incompatible changes). I have cleared this for KDM, XDM and Shadow; I just need Slim (which is still broken for a series of reasons). I've written TONS of stuff about it already, and it's not even ready for deployment; before deployment I'll have some more "official" documentation for sure: http://blog.flameeyes.eu/2010/10/24/new-pambase-choices http://blog.flameeyes.eu/2010/11/09/pam-logging-in-and-changing-passwords http://blog.flameeyes.eu/2010/11/11/draft-article-5307 but the point of this one bug is that _as the maintainer of pambase_ I do _not_ want for GDM to depend on pambase with those two USE flags. And I'm seriously getting tired of hearing "but we know better for the users and this gives a consistent behaviour" because _it is false_; it WOULD have given a consistent behaviour of the DMs actually were consistent with the rest; it WOULD have worked if shadow wasn't revert two years ago and I didn't notice ("thanks" to confmem) up until Samuli told me. PAM might not be rocket science but _nobody gave a damn about it in the past five years_ and most people keep saying "Oh I don't want to start messing with it"; I'm trying to cleanup a fucked-up situation and what I find in front of me? Challenges because I don't know enough of the issue? Are you kidding me? How many weeks is it going to take for GNOME to accept that they have botched those harddeps and they should drop them? Do I have to get QA and Council involved to actually get it noted that I am the one who has a plan? Do I have to get it posted on -dev five times with Ciaran&Co. bikeshedding it as any other of my suggestions? If I then decide to "screw it, someone else can do it", is there going to be someone else stepping in to maintain it, or would it end up with Constanze having to learn the hell that PAM is alone — like it happened with ALSA? + 11 Nov 2010; Samuli Suominen <ssuominen@gentoo.org> gdm-2.20.10-r2.ebuild, + gdm-2.20.11.ebuild, gdm-2.28.2-r1.ebuild, gdm-2.32.0.ebuild: + Remove false PDEPEND on pambase wrt #344989: GDM doesn't use + pam_ck_connector.so and works without. Ok, I still don't get what you really want for the future of pam but since our almighty ssuominen with his all power QA hat decided to mess with the changes himself, I'll let it be since it'll obviously only lead to hatred from people I value... I want, hopefully before end of the year, for users to just have to enable flags on _one_ package (pambase) and have all login managers (shadow, qingy, gdm, kdm, slim, entrance, you-name-it) support consolekit and gnome-keyring alike. And that means I'll be suggesting at that point users to disable the internal consolekit in gdm that is just a workaround. Again, please read http://blog.flameeyes.eu/2010/11/11/draft-article-5307 Ah thanks it's much easier to understand what you want now. I guess dropping the consolekit USE flag in gdm would be a good idea as soon as we can depend on the pambase release that provides the system-graphical-login. At this point, are login managers supposed to use this directly (symlink to it) or still use their own pam file using include statement to the one from pambase ? It's still going to be a pam file, but you can then use pamd_mimic, since it won't have to have anything custom in it. |
