| 1 |
On Thu, 2005-03-31 at 16:26 +0200, Diego "Flameeyes" Pettenò wrote: |
| 2 |
> On Thursday 31 March 2005 15:57, Mike Frysinger wrote: |
| 3 |
> > if pam_console is giving you a hard time on *BSD, then just use.mask it :P |
| 4 |
> > -mike |
| 5 |
> As I said is not a problem of bsd in this case. Just look at pam ebuild, is a |
| 6 |
> mess! |
| 7 |
|
| 8 |
Speak for youself - I think the ebuild is quite decent condition |
| 9 |
thinking about what it does. |
| 10 |
|
| 11 |
> it builds a static glib to be able to build pam_console, there's |
| 12 |
> conditional of all kinds... |
| 13 |
> Moving out pam_console (and the rest of optional pam modules, also) into |
| 14 |
> different ebuilds will make user ables to install what they need without |
| 15 |
> having a bloated ebuild with conditionals for everything. |
| 16 |
> |
| 17 |
|
| 18 |
Yeah sure, now its just another ebuild to test and update with each |
| 19 |
version bump - if I wanted to be in the KDE herd, I would have joined |
| 20 |
it. |
| 21 |
|
| 22 |
> This also allow to install/remove pam_console without need to recompile the |
| 23 |
> entire pam. |
| 24 |
> |
| 25 |
|
| 26 |
# rm -f /lib/security/pam_console.so |
| 27 |
|
| 28 |
You need to rebuild gcc to have gcj - I do not see the issue. |
| 29 |
|
| 30 |
> I still would like to see some problems deriving from the pam/pam_console |
| 31 |
> splitting. |
| 32 |
|
| 33 |
My fist down your yap. Seriously, it needs to die (like |
| 34 |
pam_console_devfs*), and any user still wanting it, should get what he |
| 35 |
asked for. |
| 36 |
|
| 37 |
|
| 38 |
-- |
| 39 |
Martin Schlemmer |
| 40 |
Gentoo Linux Developer, Desktop/System Team Developer |
| 41 |
Cape Town, South Africa |
Archives