From: Brian Harring <ferringb@gmail.com>
To: ciaran.mccreesh@googlemail.com
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: POSIX capability in Gentoo
Date: Wed, 3 Aug 2011 14:26:56 -0700 [thread overview]
Message-ID: <20110803212656.GA4212@localhost> (raw)
In-Reply-To: <20110803123421.75bb6bde@googlemail.com>
On Wed, Aug 03, 2011 at 12:34:21PM +0100, Ciaran McCreesh wrote:
> On Tue, 2 Aug 2011 17:29:29 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > That's not a "massive change" to vdb behaviour either; file
> > collisions aren't supposed to occur, as such ownership of the file is
> > basically guranteed back to a single package. Throw in
> > CONFIG_PROTECT for adjusting the behaviour, and you have a far more
> > preferable norm than "lets just leave a shit ton of .pyc/.pyo on the
> > fs".
>
> It is a massive change, since if the feature is there then people don't
> feel bad about writing lousy pkg_ functions that leave a load
> of .pyc / .pyo files all over the place.
Quoting the good spec:
"The unmerge process removes an installed package's files. It is not
covered in detail in this specification."
Aka, ebuild's should be written to assume the files they install get
wiped; there is *zero* mention of mtime, nor could any ebuild rely on
it and be compliant.
Background as to why we ever relied on mtime- it was a hack to work
around a bad implementation in portage (treewalk function); it didn't
actually know if it was replacing or what not, so mtime was what was
relied on- afaik, that being the sole reason we shoved mtime into
the vdb also.
At least from the portage standpoint, shifting away from mtime
reliance was on the radar since '05 and implemented at least
initially by '06... exact date it was released from a stable branch I
couldn't tell you, but it's been there a long while.
~brian
next prev parent reply other threads:[~2011-08-03 21:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-31 14:43 [gentoo-dev] POSIX capability in Gentoo Anthony G. Basile
2011-07-31 19:46 ` Nirbheek Chauhan
2011-07-31 20:00 ` Anthony G. Basile
2011-08-02 7:08 ` Michał Górny
2011-08-02 14:28 ` Anthony G. Basile
2011-08-02 14:31 ` Ciaran McCreesh
2011-08-02 14:51 ` Anthony G. Basile
2011-08-02 14:54 ` Ciaran McCreesh
2011-08-02 15:05 ` Anthony G. Basile
2011-08-02 15:05 ` Ciaran McCreesh
2011-08-02 15:19 ` Anthony G. Basile
2011-08-02 15:20 ` Ciaran McCreesh
2011-08-02 17:11 ` [gentoo-dev] " Duncan
2011-08-02 17:17 ` Ciaran McCreesh
2011-08-02 17:36 ` Jonathan Callen
[not found] ` <20110802173846.AF04F21C12C@pigeon.gentoo.org>
2011-08-02 17:39 ` Ciaran McCreesh
2011-08-02 20:46 ` Arfrever Frehtes Taifersar Arahesis
2011-08-03 1:19 ` Duncan
2011-08-03 0:29 ` Brian Harring
2011-08-03 11:34 ` Ciaran McCreesh
2011-08-03 21:26 ` Brian Harring [this message]
2011-08-03 21:28 ` Ciaran McCreesh
2011-08-03 21:52 ` Brian Harring
2011-08-02 15:15 ` [gentoo-dev] " Rich Freeman
2011-08-02 15:09 ` Michał Górny
2011-07-31 20:28 ` Michał Górny
2011-07-31 20:27 ` Ciaran McCreesh
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=20110803212656.GA4212@localhost \
--to=ferringb@gmail.com \
--cc=ciaran.mccreesh@googlemail.com \
--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