From: Mike Frysinger <vapier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] developer profile, FEATURES=digest
Date: Mon, 28 Mar 2011 13:09:33 -0400 [thread overview]
Message-ID: <AANLkTikTJWCXuSFB5f46H2B2cKGMd3=h7tPRdB1NqRbp@mail.gmail.com> (raw)
In-Reply-To: <AANLkTim4j_CsJj+fYa2z18M+hJcNCTbpLc0QoEXvScez@mail.gmail.com>
On Mon, Mar 28, 2011 at 1:03 PM, Mike Frysinger wrote:
> On Mon, Mar 28, 2011 at 11:43 AM, Christoph Mende wrote:
>> On Mon, 2011-03-28 at 16:57 +0200, Thomas Kahle wrote:
>>> On 13:13 Sun 27 Mar , "Paweł Hajdan, Jr." wrote:
>>> > FEATURES=digest results in a scary warning and a possibly dangerous
>>> > re-generation of manifests at the beginning of every emerge:
>>> >
>>> > * The FEATURES=digest setting can prevent corruption from being noticed.
>>> > * The `repoman manifest` command is the preferred way to generate
>>> > * manifests and it is capable of doing an entire repository or category at
>>> > * once.
>>> >
>>> > However, FEATURES=digest is enabled in the developer profile, and only
>>> > in that profile:
>>> >
>>> > $ egrep '^FEATURES=.*digest' -r /usr/portage/profiles/
>>> > /usr/portage/profiles/targets/developer/make.defaults:FEATURES="collision-protect
>>> > digest multilib-strict sign splitdebug stricter test test-fail-continue
>>> > userpriv usersandbox"
>>> >
>>> > I'd like to suggest removing "digest" from the line above. I've been
>>> > running with the developer profile and -digest in /etc/make.conf, and
>>> > everything is working fine.
>>>
>>> +1.
>>>
>>> I disabled it on the first day and never had any issues.
>>
>> I guess the real question here is: why was it enabled?
>
> because doing active development on ebuilds by definition invalidates
> the manifest. portage didnt use to whine about it at all. a lot
> easier to `emerge foo` without having to manually run `ebuild foo
> manifest` all the damn time.
>
> personally, i use FEATURES=digest on my development machine, but i can
> see how people would find this undesirable as a profile default.
oh, and i'm fairly certain that it used to only rebuild Manifests as
necessary (instead of blindly doing it all the time), and it used to
not check the digests of missing files. the latter though now is
available through FEATURES=assume-digests.
-mike
next prev parent reply other threads:[~2011-03-28 17:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-27 11:13 [gentoo-dev] developer profile, FEATURES=digest "Paweł Hajdan, Jr."
2011-03-28 14:57 ` Thomas Kahle
2011-03-28 15:43 ` Christoph Mende
2011-03-28 17:03 ` Mike Frysinger
2011-03-28 17:09 ` Mike Frysinger [this message]
2011-03-28 18:18 ` justin
2011-03-28 18:40 ` Mike Frysinger
2011-03-28 19:01 ` Christoph Mende
2011-03-28 17:32 ` Markos Chandras
2011-04-02 16:22 ` "Paweł Hajdan, Jr."
2011-04-02 17:08 ` Mike Frysinger
2011-04-02 20:39 ` "Paweł Hajdan, Jr."
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='AANLkTikTJWCXuSFB5f46H2B2cKGMd3=h7tPRdB1NqRbp@mail.gmail.com' \
--to=vapier@gentoo.org \
--cc=gentoo-dev@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