From: hasufell <hasufell@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Portage performance dropped considerably
Date: Tue, 28 Jan 2014 04:19:04 +0100 [thread overview]
Message-ID: <52E721A8.5050805@gentoo.org> (raw)
In-Reply-To: <slrnlee28r.ju2.martin@lounge.imp.fu-berlin.de>
On 01/28/2014 02:34 AM, Martin Vaeth wrote:
> hasufell <hasufell@gentoo.org> wrote:
>>
>> On 01/27/2014 12:26 AM, William Hubbs wrote:
>>>
>>> No, starting with USE="-*" is very dangerous.
>>
>> That's nonsense imo
>
> No, William is completely right.
>
>> and I use that setup on multiple servers/routers without any issues.
>
> No one doubts that it is *possible* to add the correct USE for
> every single package manually, but it is not a good idea to hide
> the recommended defaults.
>
As someone who writes those recommendations, I disagree. That's why many
of my packages don't have a lot of them, because I don't like them in
the first place. Another nice thing you can do is mess with USE_ORDER.
And now don't tell me that is another bad idea. This is Gentoo.
>> It makes sense because you have the most minimal setup possible
>
> This is not true, to start with: For instance, USE=minimal will
> usually choose a more minimal setup.
> With "-*" you will actually *disable* the default USE=minimal
> for e.g. www-client/firefox, x11-apps/startx, sys-block/blocks,
> dev-db/unixODBC, ... and thus get a setup which is even larger
> than the recommended default.
>
USE="-* minimal"
>> most minimal codepaths possible which reduces exposure to bugs.
>
> No, you usually get less tested (and by upstream considered untypical)
> codepaths which actually increases the probability to hit a bug
> nobody did hit/test yet.
>
Many defaults gentoo sets do not have anything to do with default
codepaths upstream has tested. So this argument works both ways.
Especially after a profile is activated.
> The USE="-*" approach was reasonable before EAPI=1 was introduced:
> In these days, unusual codepaths would have been set by "negative"
> USE-flags, e.g. IUSE="nocxx" for gcc.
> Nowadays, the upstream-recommended codepaths are set by default-USE-Flags
> in the ebuild, i.e. now the same is called IUSE="+cxx" in gcc.
> Using -* you disable such defaults which are usually there for a
> good reason.
As above, our defaults are not necessarily following upstream
recommendations/defaults. Apache alone should make you think about that
claim.
>
> Of course, if you know and care what every single USE-flags for every
> single package does, it does not matter much which approach you take,
> but I would guess that even in this case you need more exceptions
> in /etc/portage/package.use with USE="-*" than with USE="".
>
I made the opposite experience.
> Moreover, even for updates, it happens occassionally that a package
> gets an additional USE-flag, whose default is then usually chosen in
> such a way as the behaviour was before - so you risk dropping
> crucial behaviour on updates if you are not very careful.
>
I am careful. The amount of crucial packages on my servers are not that
big and I definitely watch _any_ update, unless I want a mysql update to
break hell.
Besides, if a useflag combination breaks something unexpectedly (e.g.
the build or unrelated features) then it's a bug (minimum is to
communicate the situation via elog). If disabling one useflag breaks the
whole package, then it's a bug. That's something the packager has to
care about and arch testers usually run all(or most?) useflag
permutations before stabilizing.
There is no excuse. Every other "breakage" is expected, because I have
disabled the features.
The power of useflags imply that I can mix them up any way I want. All
of those mixtures must be supported by the maintainer, unless he warns
the user about it through the ebuild, masks the useflag or sets an
appropriate REQUIRED_USE constraint. Otherwise... it's a bug.
next prev parent reply other threads:[~2014-01-28 3:19 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 14:35 [gentoo-user] Portage performance dropped considerably Nikos Chantziaras
2014-01-26 14:44 ` hasufell
2014-01-26 14:50 ` [gentoo-user] " Remy Blank
2014-01-26 15:24 ` eroen
2014-01-26 17:42 ` Alan McKinnon
2014-01-26 18:04 ` hasufell
2014-01-26 18:30 ` Alan McKinnon
2014-01-26 18:41 ` hasufell
2014-01-26 19:22 ` Alan McKinnon
2014-01-26 20:44 ` ny6p01
2014-01-27 5:03 ` Alan McKinnon
2014-01-27 9:27 ` Neil Bothwick
2014-01-26 23:26 ` William Hubbs
2014-01-26 23:36 ` Andreas K. Huettel
2014-01-27 0:44 ` Andreas K. Huettel
2014-01-27 11:44 ` hasufell
2014-01-28 1:34 ` Martin Vaeth
2014-01-28 3:19 ` hasufell [this message]
2014-01-28 17:45 ` Martin Vaeth
2014-01-28 18:07 ` hasufell
2014-01-29 14:24 ` Kerin Millar
2014-01-28 0:41 ` Walter Dnes
2014-01-28 1:42 ` Martin Vaeth
2014-01-28 4:02 ` Walter Dnes
2014-01-31 19:03 ` Andrew Savchenko
2014-01-31 19:13 ` Mick
2014-01-31 21:18 ` Andrew Savchenko
2014-01-31 22:12 ` Alan McKinnon
2014-02-02 9:40 ` Andrew Savchenko
2014-02-03 10:55 ` Martin Vaeth
2014-02-03 11:57 ` Greg Turner
2014-02-03 13:17 ` Martin Vaeth
2014-01-26 19:29 ` Volker Armin Hemmann
2014-01-26 19:45 ` Alan McKinnon
2014-01-26 20:10 ` Volker Armin Hemmann
2014-01-27 9:30 ` Neil Bothwick
2014-01-27 11:59 ` Tanstaafl
2014-01-27 13:06 ` Alan McKinnon
2014-01-27 13:57 ` hasufell
2014-01-27 21:48 ` Neil Bothwick
2014-01-27 21:54 ` hasufell
2014-01-27 22:57 ` Neil Bothwick
2014-01-27 23:35 ` hasufell
2014-01-28 1:35 ` Neil Bothwick
2014-02-03 14:04 ` Pandu Poluan
2014-02-03 14:16 ` Alan McKinnon
2014-02-03 16:38 ` Pandu Poluan
2014-02-04 5:12 ` Martin Vaeth
2014-01-28 1:50 ` Martin Vaeth
2014-01-30 3:50 ` hasufell
2014-01-30 18:15 ` [gentoo-user] " Stroller
2014-01-31 20:08 ` hasufell
2014-01-26 19:28 ` [gentoo-user] " Volker Armin Hemmann
2014-01-26 19:55 ` Alan McKinnon
2014-01-27 12:06 ` Helmut Jarausch
2014-01-27 21:56 ` Stefan G. Weichinger
2014-01-26 15:53 ` [gentoo-user] " Mariusz Ceier
2014-01-31 17:23 ` Andrew Savchenko
2014-01-26 16:06 ` Florian Philipp
2014-01-26 16:15 ` hasufell
2014-01-26 17:52 ` Florian Philipp
2014-01-26 18:16 ` covici
2014-03-07 19:36 ` Tom Wijsman
-- strict thread matches above, loose matches on Subject: below --
2014-01-26 15:09 Greg Turner
2014-01-26 15:32 ` [gentoo-user] " eroen
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=52E721A8.5050805@gentoo.org \
--to=hasufell@gentoo.org \
--cc=gentoo-user@lists.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