Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 5 Mar 2006, MIkey wrote:

> Mike Frysinger wrote:
>
>>> Heh heh, same place as FEATURES="noinfo noman nodoc" ;)
>>
>> not really ... those are documented in make.conf
>> -mike
>
> I have a nasty habit of always looking at make.conf.example instead of the
> man page. Plus, er, uh, I used FEATURES="noman" ;) Yeah, thats my story
> and I'm sticking to it.
>
> Regardless, I would rather see noman/nodoc/noinfo implemented in USE flags,
> so they can be applied package by package, implemented perhaps in something
> like dodoc/doman/doinfo/dohtml. In some cases I might actually want
> documentation for specific packages...
>
I hesitate to raise my head again, but why not use
FEATURES='-noman' emerge ...

(FEATURES='-noman -noinfo -nodoc' USE='doc' emerge ...
for that matter.)?

I use that sort of thing for, say,
FEATURES='-distcc ccache' MAKEOPTS='-j2'emerge ...
on some specific occasions, and it does what it looks like it should do.

Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEC2IcQa6M3+I///cRAqknAKCLiN6lc6CjIJ+O1/0cMZk7epCxUwCeP8jf
GXLqlvnzw9c10IK5vtUNnto=
=bUOU
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Sun, 2006-03-05 at 14:35 -0600, MIkey wrote:
> Mike Frysinger wrote:
> Regardless, I would rather see noman/nodoc/noinfo implemented in USE flags,
> so they can be applied package by package, implemented perhaps in something
> like dodoc/doman/doinfo/dohtml. In some cases I might actually want
> documentation for specific packages...

no{man,doc,info} is implemented within ebuild.sh, so you can
use /etc/portage/bashrc to set FEATURES="noman" on a per-package basis.

--
gentoo-dev@gentoo.org mailing list

Ferris McCormick wrote:

> I hesitate to raise my head again, but why not use
> FEATURES='-noman' emerge ...
>
> (FEATURES='-noman -noinfo -nodoc' USE='doc' emerge ...
> for that matter.)?
>
> I use that sort of thing for, say,
> FEATURES='-distcc ccache' MAKEOPTS='-j2'emerge ...
> on some specific occasions, and it does what it looks like it should do.

That is of course always an option.

But, I have a dream... That some day, some way, I will be able to control
_everything_ I need relating to building and installing via USE flags and
package.use.

I don't think using _anything_ in the environment should ever be allowed
because there is no way to track it during upgrades or automated building
(catalyst, installing from pre-packaged binaries, for examples). Not to
mention the environment is not exactly clean. Keeping track of the myriad
of ways you can alter a package build/install is a headache, I would prefer
it all be done through one consistent interface... From what I can tell,
the use of FEATURES="noman nodoc noinfo" is being deprecated anyway.

--
gentoo-dev@gentoo.org mailing list

OK sorry, all those Re:'s were really getting to me :)

--
Role: Gentoo Linux Kernel Lead
Gentoo Linux: http://www.gentoo.org
Public Key: gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515

On Sunday 05 March 2006 17:38, MIkey wrote:
> Ferris McCormick wrote:
> > I hesitate to raise my head again, but why not use
> > FEATURES='-noman' emerge ...
> >
> > (FEATURES='-noman -noinfo -nodoc' USE='doc' emerge ...
> > for that matter.)?
> >
> > I use that sort of thing for, say,
> > FEATURES='-distcc ccache' MAKEOPTS='-j2'emerge ...
> > on some specific occasions, and it does what it looks like it should do.
>
> That is of course always an option.
>
> But, I have a dream... That some day, some way, I will be able to control
> _everything_ I need relating to building and installing via USE flags and
> package.use.

or if we had per-package env files, FEATURES would be just fine
-mike
--
gentoo-dev@gentoo.org mailing list

On Saturday 04 March 2006 17:00, Carsten Lohrke wrote:
> On Saturday 04 March 2006 16:43, Dan Armak wrote:
> > If you're concerned about diskspace you can filter out /usr/share/doc
> > entirely, so users do have the choice. The problem here is that the
> > docs USE flag is off by default. Making more packages use the flag
> > would install less docs. Has anyone actually complained that too many
> > docs are installed by default? It's true that some users/situations
> > don't need them, but most do, especially as long as we don't have
> > separate server profiles.
>
> I have seen quite a few bugs about that and actually have filed one¹,
> rotting in bugzilla, myself. I definitely do not care about a few
> hundred KB documentation per ebuild, but some install a lot of
> documentation and accumulated it's a lot of wasted space. Filtering out
> /usr/share/doc as a whole is no choice, when you usually want it, but a
> fair share not.
>
I guess some advanced /etc/portage/bashrc magic isn't enough for you?
There are some neat tricks you can play with that.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Sunday 05 March 2006 23:38, MIkey wrote:
>
> That is of course always an option.
>
> But, I have a dream... That some day, some way, I will be able to
> control _everything_ I need relating to building and installing via USE
> flags and package.use.
>
> I don't think using _anything_ in the environment should ever be
> allowed because there is no way to track it during upgrades or
> automated building (catalyst, installing from pre-packaged binaries,
> for examples). Not to mention the environment is not exactly clean.
> Keeping track of the myriad of ways you can alter a package
> build/install is a headache, I would prefer it all be done through one
> consistent interface... From what I can tell, the use of
> FEATURES="noman nodoc noinfo" is being deprecated anyway.

Take a look at the options offered by a custom /etc/portage/bashrc. One
can do almost anything there. You can have it read in configuration files
and whatever. The documentation is kindof lacking, but most portage
features could actually be removed in favour of a custom bashrc. It would
just confuse the hell out of users.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Saturday 04 March 2006 17:02, Carsten Lohrke wrote:
> On Saturday 04 March 2006 02:04, Ciaran McCreesh wrote:
> > This is undocumented and unofficial, so feel free to utterly ignore
> > it and commit whatever the heck you want.
> >
> > The 'doc' and 'examples' (yay for consistency!)
>
> Don't now, if I guess right what you want to say, but there's no plural
> of documentation afaik. ;p

Documentation is uncountable. So no singular or plural ;-)

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

Paul de Vrieze wrote:

> Take a look at the options offered by a custom /etc/portage/bashrc. One
> can do almost anything there. You can have it read in configuration files
> and whatever. The documentation is kindof lacking, but most portage
> features could actually be removed in favour of a custom bashrc. It would
> just confuse the hell out of users.

What versions of portage implement that?

--
gentoo-dev@gentoo.org mailing list

On Monday 06 March 2006 18:11, MIkey wrote:
> Paul de Vrieze wrote:
> > Take a look at the options offered by a custom /etc/portage/bashrc. One
> > can do almost anything there. You can have it read in configuration files
> > and whatever. The documentation is kindof lacking, but most portage
> > features could actually be removed in favour of a custom bashrc. It would
> > just confuse the hell out of users.
>
> What versions of portage implement that?

The hooks to all ebuild functions are only implemented in later prereleases.
General bashrc has been supported for a long time. Any current portage
version supports it.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Monday 06 March 2006 17:39, Paul de Vrieze wrote:
> I guess some advanced /etc/portage/bashrc magic isn't enough for you?
> There are some neat tricks you can play with that.

I consider this sort of ugly hack. And I don't see the point why everyone
should do this, while a maintainer, even when the install script doesn't
allow to omit doc processing, can - as the very least - add

use doc || rm -rf ${D}/usr/share/doc/${PF}/<foo>

at the end of src_install, when megabytes of api docs etc. get installed. The
maintenance cost is zero.


Carsten

On Monday 06 March 2006 17:49, Paul de Vrieze wrote:
> Documentation is uncountable. So no singular or plural ;-)

Uh, that was meant ironic, considering Ciaran's remarks to others, that they
should know about this or that, leading to the one or the other inflaming
thread. But thanks for the explanation. ;)


Carsten

> On Monday 06 March 2006 17:39, Paul de Vrieze wrote:
>
>>I guess some advanced /etc/portage/bashrc magic isn't enough for you?
>>There are some neat tricks you can play with that.
>

While magic is great, it is also not for all end users. bashrc magic is
not officially supported by the Portage team, so while it's a powerful
tool for some users, it's also quite volatile in terms of how it is
sourced. It should not be depended on.

-Alec Warner
--
gentoo-dev@gentoo.org mailing list

Stuart Herbert posted
<b38c6f4c0603040715r2455faedy36e4dca4c06fb8c2@mail.gmail.com>, excerpted
below, on Sat, 04 Mar 2006 15:15:30 +0000:

> On 3/4/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
>> Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't
>> slow anything down, doesn't introduce any dep bloat and generally
>> doesn't change anything noticeable isn't a USE flag that's giving the
>> user any meaningful choice or making things easier for arch teams. You
>> do not get bonus points for using more USE flags.
>
> Another point of view are servers, where there's simply no need to
> have docs installed on each and every box in a rack. There's no need
> to install what a user doesn't need, and having doc and example USE
> flags more widely supported means that Gentoo does a better job of
> respecting the choice of users.

You are correct -- a server doesn't need all that stuff, and indeed,
shouldn't have it, particularly examples, as that's just more stuff
that might be exploitable in some way. However, the standard answer there
is that users should use INSTALL_MASK for docs and examples and the like
on servers. That's more dependable than a USE flag that may or may not be
there, and leaves the USE flags for the egregious cases, as Ciaran
suggested, thus effectively giving the user a tri-state control instead of
forcing a binary-state control where it doesn't really fit. (Note that
INSTALL_MASK files are still created, so someone INSTALL_MASKING will want
to negate the appropriate USE flags as well, to avoid the non-trivial
merge-time processing case.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

MIkey posted <200603041818.k24IIJCS011711@gw.open-hosting.net>, excerpted
below, on Sat, 04 Mar 2006 12:18:22 -0600:

> Ciaran McCreesh wrote:
>
>> On Sat, 04 Mar 2006 12:04:11 -0600 MIkey <mikey@badpenguins.com> wrote:
>> | At my job we aim to eventually rid ourselves completely of MS
>> | products on several thousand (local and remote) desktops and replace
>> | them with some sort of thin linux client running the citrix metaframe
>> | client. They will be running in kiosk mode. No user will have the
>> | ability to get to a window manager and browse around
>> | in /usr/share/doc. They don't even know what the heck a man page is.
>>
>> Then you should use INSTALL_MASK, not a USE flag.
>
> Please excuse my ignorance, but what the heck is INSTALL_MASK and where is
> it documented? Can it exclude things from being included in binary
> packages?

INSTALL_MASK is similar to the CONFIG_PROTECT and CONFIG_PROTECT_MASK
portage variables in that it takes a list of directories (or files,
wildcarding is acceptable), settable in make.conf. portage will still
package those files in binary packages, but won't install anything that
matches INSTALL_MASK. Thus, you can stick /usr/doc and /usr/share/doc in
it, and snag anything that would be installed to them.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list