[gentoo-dev] Lastrite: gnomevfs-mount
+# Samuli Suominen (04 Jan 2011) +# Replaced by gvfs-mount from gnome-base/gvfs. +# Masked for removal in 30 days. +sys-fs/gnomevfs-mount or udisks --mount, or pmount, ... pick your poison, this one ain't it :)
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Tue, 04 Jan 2011 10:51:06 +0200 Samuli Suominen wrote: > To fix the eclasses, and several ebuilds in tree to not do this for > something that "might be a problem" or fix the PMS wording to match > reality? Reality is that what you're doing has been problematic, which is why PMS contains the wording that it does. That you happen to have gotten away with it in a particular case is not grounds for amending the specification to incorrectly claim that the general case will work. You may find it helpful to investigate exactly what "reality" is. As is often the case, "reality" is not "what you want it to be". If you really want PMS changed, you'll need to produce a list of specific behaviours that have consistently been safe. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On 01/04/2011 10:22 AM, Ciaran McCreesh wrote:
> On Mon, 03 Jan 2011 16:40:57 +0200
> Samuli Suominen wrote:
>> Far as I know, S= isn't used to generate metadata cache, so it's PMS
>> that need fixing for it's wording:
>>
>> "All ebuild-defined variables used to generate metadata cache,
>> discussed in this chapter..."
>
> There's also:
>
> Global variables must only contain invariant values
> (see~\ref{sec:metadata-invariance}). If a global variable's value is
> invariant, it may have the value that would be generated at any
> given point in the build sequence.
>
> which is true for all global variables, not just for metadata ones.
> That paragraph's there because historically global variables have done
> various different things (being re-evaluated for every phase, or just
> some phases, or never, or when loaded from VDB, or ...).
>
I don't know the code involving package managers here, but we have
eclasses like qt4-r2.eclass and kde4-meta.eclass redefining S= from
src_unpack() and I haven't seen a single bug report about it.
To fix the eclasses, and several ebuilds in tree to not do this for
something that "might be a problem" or fix the PMS wording to match reality?
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, 03 Jan 2011 16:40:57 +0200
Samuli Suominen wrote:
> Far as I know, S= isn't used to generate metadata cache, so it's PMS
> that need fixing for it's wording:
>
> "All ebuild-defined variables used to generate metadata cache,
> discussed in this chapter..."
There's also:
Global variables must only contain invariant values
(see~\ref{sec:metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any
given point in the build sequence.
which is true for all global variables, not just for metadata ones.
That paragraph's there because historically global variables have done
various different things (being re-evaluated for every phase, or just
some phases, or never, or when loaded from VDB, or ...).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: Deprecate EAPIs 0 and 1?
Hi, Donnie Berkholz : > rather than trying to build up a > mental stack of added and removed features across multiple levels. I always recommend the Reference Card which fits on one page and sums up most features of the EAPIs (found as the last two pages of PMS). V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
