Re: Design for extensible passwd[/shadow?] db support

[Rich Felker <dalias@aerifal.cx>]

On Mon, Aug 13, 2012 at 11:41:47AM +0200, Arvid E. Picciani wrote:
> On Sun, 12 Aug 2012 16:56:43 -0400, Rich Felker wrote:
> 
> >I don't follow. What alternative are your proposing?
> 
> push user lookup up the stack and force ancient code to link in the
> high level lib.

"Intentionally break or omit a required standard interface in POSIX
and require every application needing the functionality to pull in
some third-party library" is not a plan that sounds appealing to me.

> imo, getpwent and the link don't belong into libc. They're only

Well that's up to the Austin Group, not you. We implement POSIX.
Unlike glibc, which (used to) implement Drepper's idea of what POSIX
should be changed to. Thankfully now that's changing.

> there because ancient unix
> systems had a lot of tools that shared that functionality and an
> extra lib would seem
> bloat for the little functionality they offered (basicly, it's a
> shared /etc/passwd parser,
> not a user lookup per se). Then glibc wanted more then that, out of
> a real need, and crammed
> it into libc as well, because of the inability to break compatibility.
> Now, musl _can_ break compatibility with GNU/Linux. Especially if
> it's just "link against another lib".
> 
> Then you can go to full lengths and rebuild the whole idea of user
> lookup, auth, etc.
> Another grief i have with PAM is that it is orthogonal to libc.
> 
> For a dynamic loaded system, if you design the interface carefully,
> this means you can exchange
> the auth/user/whatever lib with something else at the packaging level.
> For a static linked system, it makes no difference at all.

Making /bin/ls depend on dynamic loading modules is a bit
disgusting...

Rich