| 1 |
On Thursday 31 March 2005 17:01, Mike Frysinger wrote: |
| 2 |
> this is so that we (1) dont have to force -fPIC onto libglib.a and (2) we |
| 3 |
> dont have to move libglib.so into /lib |
| 4 |
I know why it's there.. is also stated clearly on ebuild and the changelog :) |
| 5 |
|
| 6 |
> eh, you're going to have 'bloat' regardless of using 1 ebuild or 10, it's |
| 7 |
> just a matter of which kind of bloat you want :p ... and generally i'm |
| 8 |
> against splitting packages |
| 9 |
Well.. seeing how other things are getting done with plugins, as pam modules |
| 10 |
are just plugins, for example xmms, bmp or gstreamer, the current trend is to |
| 11 |
split the ebuilds, instead of adding a lot of useflags. |
| 12 |
|
| 13 |
Also, counting that pam_console and the other optional pam_* modules aren't |
| 14 |
part of original Linux-PAM makes me prefer having a different ebuild for them |
| 15 |
instead of a single largest one. |
| 16 |
|
| 17 |
Well, that's obviously IMHO. Having a virtual/pam and |
| 18 |
virtual/pam-base-modules is enough to make the openpam interoperability i'd |
| 19 |
like to have. |
| 20 |
|
| 21 |
And just to make it clear, it's on Linux that I can't build pam_console, I |
| 22 |
haven't tried on fbsd, anyway. |
| 23 |
|
| 24 |
-- |
| 25 |
Diego "Flameeyes" Pettenò |
| 26 |
http://wwwstud.dsi.unive.it/~dpetteno/ |
Archives