Forwarding on behalf of Diego. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
--- Begin Message ---On Thu, 22 Mar 2007 09:46:24 -0500 Grant Goodyear <[EMAIL PROTECTED]> wrote:> 1. Pam cleanup and packaging. Although we're no longer using the > infamous RedHat patch sequence for linux-pam, we're still using > various not-quite-random patches. It would be really useful to have > a student work with other distros and upstream to create something > that is better standardized. Diego would be a good person to talk > to about this, if he's willing (and it's understandable if he > isn't). Okay, let me try to summarise the status of PAM when I left it (I suppose the same is now, isn't it?). pam-0.78 is still the latest stable; it's almost entirely what Martin (azarah) left me as "legacy"; I did the least work I could on that one, as it's a mess of a package. What I worked on (and what is currently in ~arch) is 0.99 series, which is quite improved: - the RedHat patches are no more applied; I don't really care about them myself, the important ones are taken up by upstream soon enough usually; - pam_stack is no more built, this is not only because of the above point, RedHat itself does not ship with it anymore, preferring the include directive too; - pam_console is no more an useflag, it is instead its own package (sys-auth/pam_console), which allows the first point once again; Gentopia, rather than PAM herd, maintains it; - pam_userdb (berkdb support) is split out in its own package, as it requires a BerkDB static PIC library; (1) - it still is called sys-libs/pam rather than the (expected imho) sys-auth/linux-pam; note that the Linux there is part of the name, it is used by Mac OS X too though; - I'm still monitoring Linux-PAM releases so I will probably find way to proxy them if noone else steps up to maintain it (I'm either masochist, or too good, you to decide). The only point I do know in this being of trouble, is (1), as it is we have a fork of BerkDB being built in pam_userdb which doubles its maintainership; I've mailed pauldv a few weeks ago as I found that troublesome: > Hi :) > > I hope you have some time to think about one thing with me... I've > been looking at PAM.. the current situation for 0.78 is a mess, > sys-libs/pam builds a static PIC version of berkdb to link to > pam_userdb; on 0.99 I've moved pam_userdb on its own package, so that > the building of berkdb does not mess up the main ebuild. > Still, it's suboptimal, as eventual security fixes on berkdb wouldn't > be applied, and there are other problems with this approach too. > > So basically the proper choices I can think of are to ask you to > either a) install a _p.a version of berkdb that would be static but > PIC-compiled or b) copy berkdb library in /$(get_libdir) and link > dynamically. > > What do you think? Unfortunately Paul does not seem to have much time lately (he answered me though, but I leave up to him to quote his mail or not). About the "various" patches.. in sys-libs/pam we currently apply three (3) patches, no more. Two are trivial patches to configure.ac to allow disabling a few features (manpages regeneration, to avoid depending on docbook and a lot of extra tools, and berkdb to avoid building pam_userdb together with main ebuild), the other is a *huge* patch to almost every Makefile.am to fix linking of modules, as they currently use LDFLAGS variables, which was proved unreliable (beside being broken semantically). All of them are sent upstream, there's no point in having a student repeat this to upstream again, at least not at with $5000 at stake. Upstream stance on the huge patch, which is the only one bothersome, is that he would like to do it another way.. he didn't commit any fix yet, I can probably just poke him to ask him what he thinks, I just didn't care much after leaving for doing this already. For more information about it, see [1] (yes, my blog is usually written as a future reference of why something has been done some particular way). This is far from saying that PAM is all well and ready and users relying on PAM can sleep nicely even if the last developer working on it (me) has gone; there *are* tasks that has to be done, but I doubt that a SoC project would be good for them: - the first thing is to write the infamous upgrade guide I talked about more than once [2], that I was going to write.. and now I'm not (really, I would have hated to do it before, now I have a perfectly good reason *not* to write it); upgrading from 0.78 to 0.99 should be fine for most desktop users, especially if they installed in the few past months, as they got all the pam.d files with include directive rather than pam_stack.so; - the second thing is that the pam.d files installed should be _all_ checked to make sure that they weren't converted wrongly, so that eventual additional restrictions are not totally ignored (see bug #151173[3]); this is something that relates with Quality Assurance of the final product, but to avoid misunderstanding, let's call this Donald Duck; it needs a Donald Duck team to look after *all* the packages; I would have done it myself, after ALSA stuff was finished.. *shrug* - keywording is not complete, see bug #152713[4], alpha and mips are missing. And to whoever is going to get into handling PAM from now on.. "Welcome on my nightmare"... feel free to ask if you need assistance, but remember I hated this too. [1] http://farragut.flameeyes.is-a-geek.org/articles/2007/01/19/yesterdays-pam-problems-are-todays-problems-too [2] http://farragut.flameeyes.is-a-geek.org/articles/2007/01/23/sometimes-youre-saved… (note the ellipses at the end please) [3] http://bugs.gentoo.org/show_bug.cgi?id=151173 [4] http://bugs.gentoo.org/show_bug.cgi?id=152713 -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/
signature.asc
Description: PGP signature
--- End Message ---
pgpd4S25gZl6l.pgp
Description: PGP signature
