public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Diego \"Flameeyes\" Pettenò" <flameeyes@users.berlios.de>
To: gentoo-dev@robin.gentoo.org
Subject: Re: [gentoo-dev] PAM related: pam_console ?
Date: Thu, 31 Mar 2005 17:17:40 +0200	[thread overview]
Message-ID: <200503311717.44937@enterprise.flameeyes.is-a-geek.org> (raw)
In-Reply-To: <200503311001.14447.vapier@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Thursday 31 March 2005 17:01, Mike Frysinger wrote:
> this is so that we (1) dont have to force -fPIC onto libglib.a and (2) we
> dont have to move libglib.so into /lib
I know why it's there.. is also stated clearly on ebuild and the changelog :)

> eh, you're going to have 'bloat' regardless of using 1 ebuild or 10, it's
> just a matter of which kind of bloat you want :p ... and generally i'm
> against splitting packages
Well.. seeing how other things are getting done with plugins, as pam modules 
are just plugins, for example xmms, bmp or gstreamer, the current trend is to 
split the ebuilds, instead of adding a lot of useflags.

Also, counting that pam_console and the other optional pam_* modules aren't 
part of original Linux-PAM makes me prefer having a different ebuild for them 
instead of a single largest one.

Well,  that's obviously IMHO. Having a virtual/pam and 
virtual/pam-base-modules is enough to make the openpam interoperability i'd 
like to have.

And just to make it clear, it's on Linux that I can't build pam_console, I 
haven't tried on fbsd, anyway.

-- 
Diego "Flameeyes" Pettenò
http://wwwstud.dsi.unive.it/~dpetteno/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-03-31 15:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-31 13:17 [gentoo-dev] PAM related: pam_console ? Diego "Flameeyes" Pettenò
2005-03-31 13:27 ` Mike Frysinger
2005-03-31 13:34   ` Diego "Flameeyes" Pettenò
2005-03-31 13:57     ` Mike Frysinger
2005-03-31 14:26       ` Diego "Flameeyes" Pettenò
2005-03-31 15:01         ` Mike Frysinger
2005-03-31 15:17           ` Diego "Flameeyes" Pettenò [this message]
2005-04-06 21:47         ` Martin Schlemmer
2005-04-07  7:34           ` [gentoo-dev] bootstrap.sh and /var/lib/portage/world mathias
2005-04-07 13:08             ` Chris Gianelloni
2005-04-06 21:41   ` [gentoo-dev] PAM related: pam_console ? Martin Schlemmer
2005-03-31 20:38 ` Robin H. Johnson
2005-03-31 21:09   ` Diego "Flameeyes" Pettenò
2005-03-31 21:35     ` Mike Frysinger
2005-03-31 22:19       ` Diego "Flameeyes" Pettenò
2005-04-06 21:52         ` Martin Schlemmer
2005-04-06 21:40 ` Martin Schlemmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503311717.44937@enterprise.flameeyes.is-a-geek.org \
    --to=flameeyes@users.berlios.de \
    --cc=gentoo-dev@gentoo.org \
    --cc=gentoo-dev@robin.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox