Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[William Hubbs]

On Thu, Mar 29, 2012 at 07:37:15PM -0700, Alec Warner wrote:
> On Tue, Mar 27, 2012 at 1:03 PM, William Hubbs  wrote:
> > On Tue, Mar 27, 2012 at 05:19:10PM +0200, "Paweł Hajdan, Jr." wrote:
> >> On 3/26/12 7:20 PM, Mike Gilbert wrote:
> >> > On Mon, Mar 26, 2012 at 1:08 PM, "Paweł Hajdan, Jr."
> >> >  wrote:
> >> >> I posted this issue here because it's not obvious what to do with it.
> >> >> That version of pybugz worked for me before (20 February 2012).
> >> >>
> >> >> Any ideas?
> >> >>
> >> > I'm guessing it was broken by the upgrade from Bugzilla 4.0 to Bugzilla 
> >> > 4.2.
> >> >
> >> > I think you should file a bug for pybugz. :)
> >>
> >> Right, and indeed I've found existing
> >>  (there is patch inside).
> >
> > That is now merged into pybugz-, but it had nothing to do with the
> > bugzilla 4.2 issues.
> >
> > I will see what else I can come up with, but patches/suggestions are
> > welcome.
> >
> > William
> >
> 
> My plan is to add support for the jsonrpc api, which I was going to do
> this weekend.

Go for it; actually I wouldn't have a problem with us converting over to
that and dropping the old method of communicating with bugzilla.

William


pgpSxQAi5Achc.pgp
Description: PGP signature

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Zac Medico]

On 03/31/2012 04:25 PM, Walter Dnes wrote:
> On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote
>> On 03/31/2012 06:34 AM, Pacho Ramos wrote:
>>> About the wiki page, I can only document reiserfs+tail usage as it's the
>>> one I use and I know, about other alternatives like using squashfs, loop
>>> mount... I cannot promise anything as I simply don't know how to set
>>> them.
>>
>> Squashfs is really simple to use:
>>
>>mksquashfs /usr/portage portage.squashfs
>>mount -o loop portage.squashfs /usr/portage
> 
>   Don't the "space-saving filesystems" (squashfs, reiserfs-with-tail,
> etc) run more slowly due to their extra finicky steps to save space?  If
> you really want to save a gigabyte or 2, run "eclean -d distfiles" and
> "localepurge" after every emerge update.  I've also cobbled together my
> own "autodepclean" script that check for, and optionally unmerges
> unneeded stuff that was pulled in as a dependancy of a package that has
> since been removed.

Well, in this case squashfs is more about improving access time than
saving space. You end up with the whole tree stored in a mostly
contiguous chunk of disk space, which minimizes seek time.
-- 
Thanks,
Zac

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Walter Dnes]

On Sat, Mar 31, 2012 at 10:42:50AM -0700, Zac Medico wrote
> On 03/31/2012 06:34 AM, Pacho Ramos wrote:
> > About the wiki page, I can only document reiserfs+tail usage as it's the
> > one I use and I know, about other alternatives like using squashfs, loop
> > mount... I cannot promise anything as I simply don't know how to set
> > them.
> 
> Squashfs is really simple to use:
> 
>mksquashfs /usr/portage portage.squashfs
>mount -o loop portage.squashfs /usr/portage

  Don't the "space-saving filesystems" (squashfs, reiserfs-with-tail,
etc) run more slowly due to their extra finicky steps to save space?  If
you really want to save a gigabyte or 2, run "eclean -d distfiles" and
"localepurge" after every emerge update.  I've also cobbled together my
own "autodepclean" script that check for, and optionally unmerges
unneeded stuff that was pulled in as a dependancy of a package that has
since been removed.

-- 
Walter Dnes 

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Zac Medico]

On 03/31/2012 01:56 PM, Ulrich Mueller wrote:
>> On Sat, 31 Mar 2012, Tiziano Müller wrote:
>> and since "pkg_pretend is run separately from the main phase
>> function sequence, and does not participate in any kind of
>> environment saving" it is not guaranteed to be set to the same $T
>> later.
> 
> The problem is that apart from T (and maybe HOME), there seems to be
> no other directory that check_reqs.eclass could use for its disk space
> check in pkg_pretend. WORKDIR doesn't exist in pkg_* phases.

How about PWD?
-- 
Thanks,
Zac

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Markos Chandras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/31/2012 10:52 AM, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 12:44:03 +0300 Alex Alexander
>  wrote:
>> @preserved-libs works very well and is awesome. hack or not. IMO
>> it should be in stable already. I've been using it on stable
>> production boxes for years without any issues :)
> 
> ...and here we see the problem. You think that "I haven't noticed
> it break" means "it works".
> 
> The problem with preserved-libs (and emerge --jobs, for that
> matter) is that the design is "I can think of a few ways where it
> might break, so I'll hard-code in special cases to handle those,
> but in general I can't think of what other problems there are so
> it's fine". That's a bad way of doing things.
> 
You are right, it does not work as good as it should but it's still
better than nothing ;) In any case, I am glad portage developers did
not backport this feature to 2.1.X portage releases as it is quite
fragile at the moment.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPd3USAAoJEPqDWhW0r/LCeI0P/2YheKfgLeAYwU/0A9RRW/UK
IXquEnUzYbYO8Y9YW8SH6V2+P3LZxye/HMJIEgv4Fy835cToVE7bUcxlizssdz5g
KllHYGBitTsd3akThmO58G2gr8BqgO7u0CkArfy8N8ulLPUigrpkdoFxSOdhTlFz
Qf2+VLhjGxN3iumAZYSG6Af+88W5P+HjhHiTCRU75M4PnL62/wCZHEBtbY7YUImS
0zsJo8fvYkCu0mqZQyguCfX5gi3elr2PQ/wSI72N2GhGsOHEw4KR3D/gDXmwFJw6
W/ymuWrmxUJtSjhFjwVxo5ZqYqiu35CSNlOA4nth6iiMNoNRsvDpIG3HploCzsBB
Gf8EA3DYfIaSkihzm/uKFbaJ/kt3n6cm8Jv8dE5MGt4f263pgV3VbRY0gXMTesRF
A+XotL46OmnR9oH35BfbtW59yz8oYaJLrhDJpa/8t0DSXGAOqWATdKsBr0klaIyz
SOTASwZkAeVAeLZBGomVfSFlqb2yA2O+mQoRwG9aLhzEJkb0Quw/EnxF3PDiOgvH
9R2OfaczNO2DfZoa/P9bNzyzUfCQNyXh45sJztBzR2aMtvwDvSQfL5ro0L7BW/M6
O3XESHxy3xypSeAn9ZTfGnVp0taTmAW/xEo8NOqpH/jail1JZ2ywDqEGuA6q4qZ7
RLvexdxVoOd7NjoGIHhw
=XsdD
-END PGP SIGNATURE-

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Francesco Riosa]

2012/3/31 Tiziano Müller :
> Am Samstag, den 31.03.2012, 14:44 +0200 schrieb Ulrich Mueller:
>> > On Sat, 31 Mar 2012, Maciej Grela wrote:
>>
>> > I've read the PMS and I haven't found information whether this variable
>> > is supposed to be set during pkg_prepare or not.
>>
>> There is no such stage. You mean pkg_pretend, I suppose?
>>
>> > Therefore I ask, what is the proper behaviour here ? Is there
>> > documentation on what special env variables are supposed to be
>> > defined in each stage ?
>>
>> It's specified here:
>> 
>>
>> | Variable   Legal in   Consistent?    Description
>> | -
>> | T          All        Partially⁴     The full path to a temporary
>> |                                      directory for use by the ebuild.
>> |
>> | ⁴Consistent and preserved across a single connected sequence of
>> | install or uninstall phases, but not between install and uninstall.
>> | When reinstalling a package, this variable must have different
>> | values for the install and the replacement.
>>
>> > Can this be considered as a bug in paludis ?
>>
>> The spec seems to be clear that T is legal in all phases, including
>> pkg_pretend.
>
> Well, I'd say: there is no sane value you can assign to $T since you are
> not allowed to write anything anyway:

indeed it's not writing, check-reqs.eclass is reading space available
via 'df -Pm' there is something else it could use assuming
$PORTAGE_TMPDIR is worse for portability?

>
> "pkg_pretend must not write to the
> filesystem." (http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-9700010.1.2)
>
> and since "pkg_pretend is run separately from the main phase function
> sequence, and does not participate in any kind of environment saving" it
> is not guaranteed to be set to the same $T later.
>
> Cheers,
> Tiziano

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Ulrich Mueller]

> On Sat, 31 Mar 2012, Tiziano Müller wrote:

>> The spec seems to be clear that T is legal in all phases, including
>> pkg_pretend.

> Well, I'd say: there is no sane value you can assign to $T since you
> are not allowed to write anything anyway:

> "pkg_pretend must not write to the filesystem."
> (http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-9700010.1.2)

That's not necessarily a contradiction. Writing being not allowed
doesn't imply that the directory must not exist.

> and since "pkg_pretend is run separately from the main phase
> function sequence, and does not participate in any kind of
> environment saving" it is not guaranteed to be set to the same $T
> later.

The problem is that apart from T (and maybe HOME), there seems to be
no other directory that check_reqs.eclass could use for its disk space
check in pkg_pretend. WORKDIR doesn't exist in pkg_* phases.

Ulrich

Re: [gentoo-dev] ESCM_OFFLINE/ EVCS_OFFLINE env variable policy

[Justin]

On 31.03.2012 20:49, Alexander V Vershilov wrote:
> Hello.
> 
> It seems that in eclasses we have two differenct environment variables
> with same meaning ESCM and EVCS OFFLINE. Some of eclasses use one and 
> some another:
> 
>  find . -type f | xargs grep -l EVCS_OFFLINE
>  ./git-2.eclass
>  ./bzr.eclass
> 
>  find . -type f | xargs grep -l ESCM_OFFLINE
>  ./darcs.eclass
>  ./cvs.eclass
>  ./mercurial.eclass
>  ./git.eclass
>  ./subversion.eclass
> 
> It seems we should have some concusion about what env variable should 
> be used to prevent downloading of live repo.
> 
> Thanks.
> 
> --
> Alexander Vershilov
> [2048R/5E05C6C2]

Hi,

I would vote for EVCS_OFFLINE as we already agreed in the dev-vcs
discussion on vcs.

justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ESCM_OFFLINE/ EVCS_OFFLINE env variable policy

[Michał Górny]

On Sat, 31 Mar 2012 22:49:07 +0400
Alexander V Vershilov  wrote:

> Hello.
> 
> It seems that in eclasses we have two differenct environment variables
> with same meaning ESCM and EVCS OFFLINE. Some of eclasses use one and 
> some another:
> 
>  find . -type f | xargs grep -l EVCS_OFFLINE
>  ./git-2.eclass
>  ./bzr.eclass
> 
>  find . -type f | xargs grep -l ESCM_OFFLINE
>  ./darcs.eclass
>  ./cvs.eclass
>  ./mercurial.eclass
>  ./git.eclass
>  ./subversion.eclass
> 
> It seems we should have some concusion about what env variable should 
> be used to prevent downloading of live repo.

I think we agreed on using EVCS_. Quoting ulm:

Coming back to this. As was pointed out in the thread in -dev (almost a
year ago), these variables should better be named EVCS_*, because SCM
is ambiguous with the scheme language. The category is called dev-vcs
too. [1]

[1]:https://bugs.gentoo.org/show_bug.cgi?id=311101

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] ESCM_OFFLINE/ EVCS_OFFLINE env variable policy

[Alexander V Vershilov]

Hello.

It seems that in eclasses we have two differenct environment variables
with same meaning ESCM and EVCS OFFLINE. Some of eclasses use one and 
some another:

 find . -type f | xargs grep -l EVCS_OFFLINE
 ./git-2.eclass
 ./bzr.eclass

 find . -type f | xargs grep -l ESCM_OFFLINE
 ./darcs.eclass
 ./cvs.eclass
 ./mercurial.eclass
 ./git.eclass
 ./subversion.eclass

It seems we should have some concusion about what env variable should 
be used to prevent downloading of live repo.

Thanks.

--
Alexander Vershilov
[2048R/5E05C6C2]


signature.asc
Description: Digital signature

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Zac Medico]

On 03/31/2012 06:34 AM, Pacho Ramos wrote:
> About the wiki page, I can only document reiserfs+tail usage as it's the
> one I use and I know, about other alternatives like using squashfs, loop
> mount... I cannot promise anything as I simply don't know how to set
> them.

Squashfs is really simple to use:

   mksquashfs /usr/portage portage.squashfs
   mount -o loop portage.squashfs /usr/portage

-- 
Thanks,
Zac

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Jeroen Roovers]

On Sat, 31 Mar 2012 15:59:00 +0100
Ciaran McCreesh  wrote:

> > I wouldn't care if it weren't the fact your gentoo dev posts 
> > generally consist of "xyz is stupid, as is the people behind it" 
> > whether it be portage, udev, council, etc, take your pick.
> 
> No, what I actually say is *why* things don't work, and if it hasn't
> already been explained, I say how to fix it.

No, that's what you see from the inside. We, outside your head, the
others, see it precisely as Brian worded it. Some people apparently
tolerate or even appreciate your general (online) attitude towards
humans, but most do not.


 jer

Re: [gentoo-dev] Happy 10th birthday (in advance)

[David Leverton]

On 30 March 2012 14:25, Samuli Suominen  wrote:
> Back to year 2009?
>
> http://www.gentoo.org/news/20091004-gentoo-10-years.xml

That never stopped anyone before

http://en.wikipedia.org/wiki/Final_Fantasy_X-2

Re: [gentoo-dev] Re: Happy 10th birthday (in advance)

[Zac Medico]

On 03/31/2012 04:49 AM, Duncan wrote:
> Ciaran McCreesh posted on Sat, 31 Mar 2012 10:52:53 +0100 as excerpted:
> 
>> On Sat, 31 Mar 2012 12:44:03 +0300 Alex Alexander
>>  wrote:
>>> @preserved-libs works very well and is awesome. hack or not. IMO it
>>> should be in stable already. I've been using it on stable production
>>> boxes for years without any issues :)
>>
>> ...and here we see the problem. You think that "I haven't noticed it
>> break" means "it works".
> 
> Funny how familiar that argument looks... aka...
> 
> A separate /usr is already broken, you just don't know it yet.

For separate /usr, there's a relatively simple solution, which is to
mount /usr with an initramfs. For preserve-libs, there is no such a
simple solution. Much like separate-/usr-without-initramfs,
preserve-libs does not work correctly unless lots of different pieces of
software behave cooperatively.
-- 
Thanks,
Zac

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 18:39:21 +0300
Alex Alexander  wrote:
> On Mar 31, 2012 5:57 PM, "Ciaran McCreesh"
>  wrote:
> > On Sat, 31 Mar 2012 15:08:29 +0300
> > Alex Alexander  wrote:
> > > No. I didn't say I think it works, I said I have proof it works.
> >
> > Well that's interesting, because there are plenty of examples where
> > it doesn't work, and all that it takes to disprove a theory is a
> > single counterexample. So I think you're misunderstanding what
> > constitutes proof here -- "some evidence" certainly isn't it.
> 
> Boring. You conveniently ignored the other part of my message.

I was hoping you'd understand how your claim of proof was utterly
unfounded. What you have is limited evidence of a very specific
situation, which is a whole other thing.

> I'll repeat it: no matter how much you argue, it'll still work fine
> for me.

And I'll spell it out. On the scale of "it works", you have a series of
levels:

1. It compiles.

2. I tried it and I didn't see any breakages.

3. I tried it, and I checked carefully that nothing was broken.

4. I tried it on a wide range of valid inputs, and I checked carefully
that nothing was broken.

5. I tried it on a wide range of valid inputs, including inputs designed
to test edge cases, and I checked carefully that nothing was broken.

6. I tried it on a wide range of valid and invalid inputs, and I
checked carefully that nothing was broken, and that the invalid inputs
were handled correctly.

7. I carefully considered all the equivalence classes of inputs, and
tested each.

8. I carefully considered all the equivalence classes of inputs, and
can explain why each is handled correctly.

9. I can prove that it works.

You're offering evidence of number 2, or possibly 3. Gentoo is a large
system containing many interacting components, that is expected to keep
working for long periods in many different unpleasant situations. We
need to be at at least number 7 here, and ideally number 8. For preserve
libs, the feature fails at number 4.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Patrick Lauer]

On 03/31/12 23:38, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 23:30:07 +0800
> Patrick Lauer  wrote:
>>> So you think Gentoo should advertise as "the chances of it working
>>> are greater than 0%"?
>>
>> I said better ... not repetitive trolls.
>>
>> If you cared about making things better you'd spend more time writing
>> patches and less time trying to pick fights on public mailinglists :)
>>
>> But I guess small minds, small pleasures ...
> 
> What Gentoo needs is less immediate writing of patches and more careful
> thinking about how a complex mess of sort-of working, poorly
> interacting features can be unified into a smaller number of correct,
> coherent concepts. Right now most of the patches are fixing screwups in
> earlier patches that were caused by implementing the wrong thing (and
> often introducing new problems along the way).
> 
> The fact that you have code that does something does not automatically
> imply that doing it is a good idea.
> 

... and now we train not sending private messages to public mailing
lists again, mmmhkay? After so many years you still accidentally do such
things on purpose. Not cool.

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 23:30:07 +0800
Patrick Lauer  wrote:
> > So you think Gentoo should advertise as "the chances of it working
> > are greater than 0%"?
> 
> I said better ... not repetitive trolls.
> 
> If you cared about making things better you'd spend more time writing
> patches and less time trying to pick fights on public mailinglists :)
> 
> But I guess small minds, small pleasures ...

What Gentoo needs is less immediate writing of patches and more careful
thinking about how a complex mess of sort-of working, poorly
interacting features can be unified into a smaller number of correct,
coherent concepts. Right now most of the patches are fixing screwups in
earlier patches that were caused by implementing the wrong thing (and
often introducing new problems along the way).

The fact that you have code that does something does not automatically
imply that doing it is a good idea.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 5:57 PM, "Ciaran McCreesh" 
wrote:
>
> On Sat, 31 Mar 2012 15:08:29 +0300
> Alex Alexander  wrote:
> > No. I didn't say I think it works, I said I have proof it works.
>
> Well that's interesting, because there are plenty of examples where it
> doesn't work, and all that it takes to disprove a theory is a single
> counterexample. So I think you're misunderstanding what constitutes
> proof here -- "some evidence" certainly isn't it.
>
> --
> Ciaran McCreesh

Boring. You conveniently ignored the other part of my message.

I'll repeat it: no matter how much you argue, it'll still work fine for me.

That said, I think we can end this conversation now :)

Gentoo \o/

Alex | wired

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Tiziano Müller]

Am Samstag, den 31.03.2012, 14:44 +0200 schrieb Ulrich Mueller:
> > On Sat, 31 Mar 2012, Maciej Grela wrote:
> 
> > I've read the PMS and I haven't found information whether this variable
> > is supposed to be set during pkg_prepare or not.
> 
> There is no such stage. You mean pkg_pretend, I suppose?
> 
> > Therefore I ask, what is the proper behaviour here ? Is there
> > documentation on what special env variables are supposed to be
> > defined in each stage ?
> 
> It's specified here:
> 
> 
> | Variable   Legal in   Consistent?Description
> | -
> | T  AllPartially⁴ The full path to a temporary
> |  directory for use by the ebuild. 
> |
> | ⁴Consistent and preserved across a single connected sequence of
> | install or uninstall phases, but not between install and uninstall.
> | When reinstalling a package, this variable must have different
> | values for the install and the replacement.
> 
> > Can this be considered as a bug in paludis ?
> 
> The spec seems to be clear that T is legal in all phases, including
> pkg_pretend.

Well, I'd say: there is no sane value you can assign to $T since you are
not allowed to write anything anyway:

"pkg_pretend must not write to the
filesystem." (http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-9700010.1.2)

and since "pkg_pretend is run separately from the main phase function
sequence, and does not participate in any kind of environment saving" it
is not guaranteed to be set to the same $T later.

Cheers,
Tiziano


smime.p7s
Description: S/MIME cryptographic signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 23:07:04 +0800
Patrick Lauer  wrote:
> > If you have a ten components, each of which 98% work, your overall
> > system is 80% reliable. If you have twenty such components, it's
> > down to 66% reliable. You're rapidly entering "when it breaks,
> > reinstall" territory here.
> > 
> Which is still more than 0%.
> 
> I demand better trolls, this is getting boring.

So you think Gentoo should advertise as "the chances of it working are
greater than 0%"?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Patrick Lauer]

On 03/31/12 23:01, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 19:00:00 +0800
> Patrick Lauer  wrote:
>> Good enough is the worst enemy of perfect.
>>
>> While we have s 98% solution that doesn't handle all corner cases you
>> have a theoretical construct in your brain that might in theory cover
>> 100% of all cases, but it's in your brain where I can't use it, so ...
>> I'll take the pragmatic approach and use what works.
> 
> If you have a ten components, each of which 98% work, your overall
> system is 80% reliable. If you have twenty such components, it's down
> to 66% reliable. You're rapidly entering "when it breaks, reinstall"
> territory here.
> 
Which is still more than 0%.

I demand better trolls, this is getting boring.

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 19:00:00 +0800
Patrick Lauer  wrote:
> Good enough is the worst enemy of perfect.
> 
> While we have s 98% solution that doesn't handle all corner cases you
> have a theoretical construct in your brain that might in theory cover
> 100% of all cases, but it's in your brain where I can't use it, so ...
> I'll take the pragmatic approach and use what works.

If you have a ten components, each of which 98% work, your overall
system is 80% reliable. If you have twenty such components, it's down
to 66% reliable. You're rapidly entering "when it breaks, reinstall"
territory here.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 03:06:36 -0700
Brian Harring  wrote:
> > The problem with preserved-libs (and emerge --jobs, for that
> > matter) is that the design is "I can think of a few ways where it
> > might break, so I'll hard-code in special cases to handle those,
> > but in general I can't think of what other problems there are so
> > it's fine". That's a bad way of doing things.
> 
> Then don't use it.  Reality is, gentoo does.
> 
> If you don't like that fact, I suggest you stick to exherbo.
> 
> Related, why the hell are you still even around here?

Because unlike you, I believe Gentoo can and should get it right. If
users want a desktoppy distribution where stuff sort of works most of
the time but no-one really understands why, and where you reinstall
every six months, then Ubuntu already does a far better job of that.
Gentoo can deliver something better.

It's not even more work. It just requires a small change in thought
process from "code first and ask questions later" to "think first and
then code". That, together with incrementally fixing existing bad
design decisions, could bring Gentoo back towards being an extremely
attractive alternative distribution.

> I wouldn't care if it weren't the fact your gentoo dev posts 
> generally consist of "xyz is stupid, as is the people behind it" 
> whether it be portage, udev, council, etc, take your pick.

No, what I actually say is *why* things don't work, and if it hasn't
already been explained, I say how to fix it. But the first step towards
getting something fixed is admitting that there's a problem, and you've
always been awfully reluctant to do that until the damage has already
been done.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 15:08:29 +0300
Alex Alexander  wrote:
> No. I didn't say I think it works, I said I have proof it works.

Well that's interesting, because there are plenty of examples where it
doesn't work, and all that it takes to disprove a theory is a single
counterexample. So I think you're misunderstanding what constitutes
proof here -- "some evidence" certainly isn't it.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Pacho Ramos]

El sáb, 31-03-2012 a las 02:35 -0700, Brian Harring escribió:
> On Sat, Mar 31, 2012 at 08:44:02AM +, Sven Vermeulen wrote:
> > On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote:
> > > Looks then that there are several alternatives for portage tree, then,
> > > maybe the option would be to add a note to Gentoo Handbook explaining
> > > the cons of having portage tree on a standard partition and, then, put a
> > > link to a wiki page (for example) where all this alternatives are
> > > explained.
> > > 
> > > What do you think about this approach? 
> > 
> > I don't like the "cons" approach, as it gives the impression that users are
> > pushed into a negative solution, whereas the current situation works just
> > fine for almost all users. The approach for a different partition is for
> > performance reasons (which most users don't have any negative feelings
> > about) and as such might be read as a "ricer" approach.
> 
> For modern hardware w/ a modern kernel (or at least >=2.6.38 for the 
> dcache resolution optimizations)... does anyone actually have real 
> performance stats for this?
> 
> If the notion is a seperate FS, one tailored to the portage tree's 
> usage models (tail packing for example), sure, grok that although I 
> question how much people really are getting out of it.
> 
> In the past, situation definitely differed- I'm just wondering if the 
> gain is actually worth debating it, rather than just ignoring it (or 
> sticking it in a foot note for people trying to use durons).
> ~harring
> 
> 

I did performance stats one year ago or so, but I don't have time to
redo all of them to simply confirm how behave now with recent kernel (in
that time, I checked reiserfs, ext2 with multiple block sizes).
Regarding disk space usage, it's still valid today for sure


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Pacho Ramos]

El sáb, 31-03-2012 a las 08:44 +, Sven Vermeulen escribió:
> On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote:
> > Looks then that there are several alternatives for portage tree, then,
> > maybe the option would be to add a note to Gentoo Handbook explaining
> > the cons of having portage tree on a standard partition and, then, put a
> > link to a wiki page (for example) where all this alternatives are
> > explained.
> > 
> > What do you think about this approach? 
> 
> I don't like the "cons" approach, as it gives the impression that users are
> pushed into a negative solution, whereas the current situation works just
> fine for almost all users. The approach for a different partition is for
> performance reasons (which most users don't have any negative feelings
> about) and as such might be read as a "ricer" approach.
> 
> But perhaps it would be more "lean" to just start with a wiki page (or
> document) for alternative / better partitioning layouts, and when that has
> stabilized then we can talk about Handbook integration, not?
> 
> Wkr,
>   Sven Vermeulen
> 
> 

Current solution works but causes a really slow portage tree when ages
passes (I still have a machine with tree in / and is really really slow
but, since it's used by my father at his job, I am unable to solve
it :( ). And not, I don't think it's a ricer approach at all, it's for
performance and for save a lot of disk space too.

About the wiki page, I can only document reiserfs+tail usage as it's the
one I use and I know, about other alternatives like using squashfs, loop
mount... I cannot promise anything as I simply don't know how to set
them.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Ulrich Mueller]

> On Sat, 31 Mar 2012, Maciej Grela wrote:

> I've read the PMS and I haven't found information whether this variable
> is supposed to be set during pkg_prepare or not.

There is no such stage. You mean pkg_pretend, I suppose?

> Therefore I ask, what is the proper behaviour here ? Is there
> documentation on what special env variables are supposed to be
> defined in each stage ?

It's specified here:


| Variable   Legal in   Consistent?Description
| -
| T  AllPartially⁴ The full path to a temporary
|  directory for use by the ebuild. 
|
| ⁴Consistent and preserved across a single connected sequence of
| install or uninstall phases, but not between install and uninstall.
| When reinstalling a package, this variable must have different
| values for the install and the replacement.

> Can this be considered as a bug in paludis ?

The spec seems to be clear that T is legal in all phases, including
pkg_pretend.

Ulrich

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Rich Freeman]

On Sat, Mar 31, 2012 at 7:44 AM, Samuli Suominen  wrote:
> (or hand me powers to remove people from ML :-)
>

That sounds like a great idea.  We could create a code of conduct, and
then designate individuals to enforce it.  Maybe we should call them
proctors:
http://www.gentoo.org/proj/en/council/coc.xml

What could go wrong?

Seriously though, this debate like many others recently probably
shouldn't be viewed as for-Gentoo and against-Gentoo.  Lots of people
care about Gentoo, we just don't always agree on what is best.  In
this case the issue is pragmatism vs idealism, and both have their
place.

What is important is that we go ahead and share our views, debate
points within reason, don't obsess over getting in the last word, and
then work together to support the decisions that get made.

My two cents in this debate is that I'm willing to accept Ciaran's
suggestion that Portage 2.2's approach has its limitations, but it is
the best thing we have implemented now, and thus I'll take the 98%
solution over the 20% solution (which is what we get if all we do is
argue over how to get to 100%(.  If somebody wants to write the code
to get us from 98->100%, I'm sure we'll all be for it.

Rich

[gentoo-dev] Should ${T} be defined in pkg_prepare ?

[Maciej Grela]

Hi,

recently, I've tried to compile libreoffice using paludis and I've
noticed the following problem:

8< -
kraken ~ # cave resolve libreoffice
Done: 3905 steps  

These are the actions I will take, in order:

r   app-office/libreoffice:0::gentoo 3.5.2.2 to ::installed replacing
3.5.2.2
(-aqua) -binfilter branding cups dbus eds gnome graphite gstreamer
gtk -java jemalloc -kde -mysql -nlpsolver nsplugin -odk opengl pdfimport
-postgres svg vba webdav xmlsec (-test) build_options: symbols=split
-optional_tests -trace -preserve_work
Reasons: target, !=app-office/libreoffice-3.4.-r1 from
app-office/libreoffice-l10n, !=app-office/libreoffice--r1 from
app-office/libreoffice-l10n, 2 more

Total: 1 reinstalls

Executing pretend actions: 1 of 1
libreoffice-3.5.2.2>  * Checking for at least 512 mebibytes RAM ... 
[ ok ]
libreoffice-3.5.2.2> DISK CHECK: path="", size="6G"
libreoffice-3.5.2.2>  * Checking for at least 6 gibibytes disk space at 
[ !! ]
libreoffice-3.5.2.2>
libreoffice-3.5.2.2>  * Couldn't determine disk space, skipping...
8< -

the check-reqs is not getting the "${T}" value properly when it's being
run from pkg_prepare. I've added an echo to the eclass to confirm this.
The ebuild detects free space properly when run under emerge:

8< -
kraken ~ # emerge --nodeps -p -v libreoffice

These are the packages that would be merged, in order:

[ebuild   R] app-office/libreoffice-3.5.2.2::gentoo
[3.5.2.2::__unknown__] USE="branding cups dbus graphite gtk nsplugin
opengl svg vba webdav xmlsec (-aqua) -binfilter -eds* -gnome*
-gstreamer* -java -jemalloc* -kde -mysql -nlpsolver -odk -pdfimport*
-postgres -test" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

kraken ~ # emerge --nodeps -v libreoffice

These are the packages that would be merged, in order:

[ebuild   R] app-office/libreoffice-3.5.2.2::gentoo
[3.5.2.2::__unknown__] USE="branding cups dbus graphite gtk nsplugin
opengl svg vba webdav xmlsec (-aqua) -binfilter -eds* -gnome*
-gstreamer* -java -jemalloc* -kde -mysql -nlpsolver -odk -pdfimport*
-postgres -test" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB


>>> Verifying ebuild manifests
>>> Running pre-merge checks for app-office/libreoffice-3.5.2.2
 * Checking for at least 512 mebibytes RAM
... 
  
[ ok ]
DISK CHECK: path="/var/tmp/portage/app-office/libreoffice-3.5.2.2/temp",
size="6G"
 * Checking for at least 6 gibibytes disk space at
"/var/tmp/portage/app-office/libreoffice-3.5.2.2/temp"
... [ ok ]

>>> Emerging (1 of 1) app-office/libreoffice-3.5.2.2
^C

kraken ~ #
8< -


I've read the PMS and I haven't found information whether this variable
is supposed to be set during pkg_prepare or not. Therefore I ask, what
is the proper behaviour here ? Is there documentation on what special
env variables are supposed to be defined in each stage ?
Can this be considered as a bug in paludis ?

Thanks for your help.

Best regards,
Maciej Grela

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 12:57 PM, "Ciaran McCreesh" 
wrote:
>
> On Sat, 31 Mar 2012 12:44:03 +0300
> Alex Alexander  wrote:
> > @preserved-libs works very well and is awesome. hack or not. IMO it
> > should be in stable already. I've been using it on stable production
> > boxes for years without any issues :)
>
> ...and here we see the problem. You think that "I haven't noticed it
> break" means "it works".
>
> The problem with preserved-libs (and emerge --jobs, for that matter) is
> that the design is "I can think of a few ways where it might break, so
> I'll hard-code in special cases to handle those, but in general I
> can't think of what other problems there are so it's fine". That's a
> bad way of doing things.
>
> --
> Ciaran McCreesh

No. I didn't say I think it works, I said I have proof it works.

You can argue about the implementation details all you want and it'll still
work.

If you can make it better then, by all means, send a patch. Otherwise stop
spreading false FUD, please.

Thanks :)

Alex | wired

[gentoo-dev] Re: Happy 10th birthday (in advance)

[Duncan]

Ciaran McCreesh posted on Sat, 31 Mar 2012 10:52:53 +0100 as excerpted:

> On Sat, 31 Mar 2012 12:44:03 +0300 Alex Alexander
>  wrote:
>> @preserved-libs works very well and is awesome. hack or not. IMO it
>> should be in stable already. I've been using it on stable production
>> boxes for years without any issues :)
> 
> ...and here we see the problem. You think that "I haven't noticed it
> break" means "it works".

Funny how familiar that argument looks... aka...

A separate /usr is already broken, you just don't know it yet.


Or was drawing attention to that your intent and I just missed the 
invisible  tags. =:^)

-- 
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

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Samuli Suominen]

On 03/31/2012 01:06 PM, Brian Harring wrote:

On Sat, Mar 31, 2012 at 10:52:53AM +0100, Ciaran McCreesh wrote:

On Sat, 31 Mar 2012 12:44:03 +0300
Alex Alexander  wrote:

@preserved-libs works very well and is awesome. hack or not. IMO it
should be in stable already. I've been using it on stable production
boxes for years without any issues :)


...and here we see the problem. You think that "I haven't noticed it
break" means "it works".

The problem with preserved-libs (and emerge --jobs, for that matter) is
that the design is "I can think of a few ways where it might break, so
I'll hard-code in special cases to handle those, but in general I
can't think of what other problems there are so it's fine". That's a
bad way of doing things.


Then don't use it.  Reality is, gentoo does.

If you don't like that fact, I suggest you stick to exherbo.

Related, why the hell are you still even around here?

You literally send more mail to our dev ml then to exherbos.

I wouldn't care if it weren't the fact your gentoo dev posts
generally consist of "xyz is stupid, as is the people behind it"
whether it be portage, udev, council, etc, take your pick.

~harring (being rather tired of the broken record).



separate gentoo-dev@ and gentoo-dev-public@ MLs so we would have a place 
where to discuss about improving Gentoo with people who also want to 
improve it


(or hand me powers to remove people from ML :-)

- Samuli

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Patrick Lauer]

On 03/31/12 17:52, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 12:44:03 +0300
> Alex Alexander  wrote:
>> @preserved-libs works very well and is awesome. hack or not. IMO it
>> should be in stable already. I've been using it on stable production
>> boxes for years without any issues :)
> 
> ...and here we see the problem. You think that "I haven't noticed it
> break" means "it works".
> 
> The problem with preserved-libs (and emerge --jobs, for that matter) is
> that the design is "I can think of a few ways where it might break, so
> I'll hard-code in special cases to handle those, but in general I
> can't think of what other problems there are so it's fine". That's a
> bad way of doing things.
> 
Good enough is the worst enemy of perfect.

While we have s 98% solution that doesn't handle all corner cases you
have a theoretical construct in your brain that might in theory cover
100% of all cases, but it's in your brain where I can't use it, so ...
I'll take the pragmatic approach and use what works.

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Brian Harring]

On Sat, Mar 31, 2012 at 10:52:53AM +0100, Ciaran McCreesh wrote:
> On Sat, 31 Mar 2012 12:44:03 +0300
> Alex Alexander  wrote:
> > @preserved-libs works very well and is awesome. hack or not. IMO it
> > should be in stable already. I've been using it on stable production
> > boxes for years without any issues :)
> 
> ...and here we see the problem. You think that "I haven't noticed it
> break" means "it works".
> 
> The problem with preserved-libs (and emerge --jobs, for that matter) is
> that the design is "I can think of a few ways where it might break, so
> I'll hard-code in special cases to handle those, but in general I
> can't think of what other problems there are so it's fine". That's a
> bad way of doing things.

Then don't use it.  Reality is, gentoo does.

If you don't like that fact, I suggest you stick to exherbo.

Related, why the hell are you still even around here?

You literally send more mail to our dev ml then to exherbos. 

I wouldn't care if it weren't the fact your gentoo dev posts 
generally consist of "xyz is stupid, as is the people behind it" 
whether it be portage, udev, council, etc, take your pick.

~harring (being rather tired of the broken record).

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Sat, 31 Mar 2012 12:44:03 +0300
Alex Alexander  wrote:
> @preserved-libs works very well and is awesome. hack or not. IMO it
> should be in stable already. I've been using it on stable production
> boxes for years without any issues :)

...and here we see the problem. You think that "I haven't noticed it
break" means "it works".

The problem with preserved-libs (and emerge --jobs, for that matter) is
that the design is "I can think of a few ways where it might break, so
I'll hard-code in special cases to handle those, but in general I
can't think of what other problems there are so it's fine". That's a
bad way of doing things.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Alex Alexander]

On Mar 31, 2012 11:00 AM, "Ciaran McCreesh" 
wrote:
>
> On Fri, 30 Mar 2012 17:55:27 -0400
> Richard Yao  wrote:
> > I think we should wait for Portage 2.2 to be stabilized before we
> > declare Gentoo 2.0. @preserved-libs is enough of an advance that I
> > think claiming 2.0 would be merited, if only for the attention it
> > would draw at Phoronix.
>
> Do you really want to be advertising an awful hack that doesn't really
> work, is conceptually unsound and that breaks all kinds of things in
> subtle ways?
>
> --
> Ciaran McCreesh

@preserved-libs works very well and is awesome. hack or not. IMO it should
be in stable already. I've been using it on stable production boxes for
years without any issues :)

Alex | wired

[gentoo-dev] Last rites: sys-auth/tcb

[Paweł Hajdan, Jr.]

# Masked for removal, use sys-apps/hardened-shadow instead.
# Needs too much special patching to work in Gentoo,
# bugs: #371167, #408647. Removal in 60 days (31 May 2012).
sys-auth/tcb



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Brian Harring]

On Sat, Mar 31, 2012 at 08:44:02AM +, Sven Vermeulen wrote:
> On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote:
> > Looks then that there are several alternatives for portage tree, then,
> > maybe the option would be to add a note to Gentoo Handbook explaining
> > the cons of having portage tree on a standard partition and, then, put a
> > link to a wiki page (for example) where all this alternatives are
> > explained.
> > 
> > What do you think about this approach? 
> 
> I don't like the "cons" approach, as it gives the impression that users are
> pushed into a negative solution, whereas the current situation works just
> fine for almost all users. The approach for a different partition is for
> performance reasons (which most users don't have any negative feelings
> about) and as such might be read as a "ricer" approach.

For modern hardware w/ a modern kernel (or at least >=2.6.38 for the 
dcache resolution optimizations)... does anyone actually have real 
performance stats for this?

If the notion is a seperate FS, one tailored to the portage tree's 
usage models (tail packing for example), sure, grok that although I 
question how much people really are getting out of it.

In the past, situation definitely differed- I'm just wondering if the 
gain is actually worth debating it, rather than just ignoring it (or 
sticking it in a foot note for people trying to use durons).
~harring

Re: [gentoo-dev] haskell-cabal.eclass suggestions

[Sergei Trofimovich]

On Fri, 30 Mar 2012 13:59:10 +0200
""Paweł Hajdan, Jr.""  wrote:

> > echo 'import Distribution.Simple; main = defaultMainWithHooks 
> > defaultUserHooks' \
> > > $setupdir/Setup.hs
> > }
> 
> I think there should be || die after echo, to catch out-of-disk-space
> problems.

Ok :]

> > # GHC 6.4 has a bug in get/setPermission and Cabal 1.1.1 has
> > # no workaround.
> > # set the +x permission on executables
> > if [[ -d "${ED}/usr/bin" ]] ; then
> > chmod +x "${ED}/usr/bin/"*
> > fi
> > # TODO: do we still need this?
> > }
> 
> I think there should be || die after chmod.

I'll remove the whole block.

> > if [[ -z "${CABAL_HAS_BINARIES}" ]] && [[ -z "${CABAL_HAS_LIBRARIES}" 
> > ]]; then
> > eerror "QA: Neither bin nor lib are in CABAL_FEATURES."
> 
> Shouldn't this be eqawarn?
> 
> > fi
> > if [[ -n "${CABAL_UNKNOWN}" ]]; then
> > ewarn "Unknown entry in CABAL_FEATURES: ${CABAL_UNKNOWN}"
> 
> Shouldn't this be eqawarn?

'eqawarn' sounds fine here. I'll push the changes to overlay first and then to 
the gx86.

Thanks for sharing!

-- 

  Sergei


signature.asc
Description: PGP signature

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Sven Vermeulen]

On Sat, Mar 31, 2012 at 08:56:22AM +0100, Ciaran McCreesh wrote:
> Do you really want to be advertising an awful hack that doesn't really
> work, is conceptually unsound and that breaks all kinds of things in
> subtle ways?

Isn't that something all major distributions do? ;-)

Sven

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Sven Vermeulen]

On Fri, Mar 30, 2012 at 10:06:18AM +0200, Pacho Ramos wrote:
> Looks then that there are several alternatives for portage tree, then,
> maybe the option would be to add a note to Gentoo Handbook explaining
> the cons of having portage tree on a standard partition and, then, put a
> link to a wiki page (for example) where all this alternatives are
> explained.
> 
> What do you think about this approach? 

I don't like the "cons" approach, as it gives the impression that users are
pushed into a negative solution, whereas the current situation works just
fine for almost all users. The approach for a different partition is for
performance reasons (which most users don't have any negative feelings
about) and as such might be read as a "ricer" approach.

But perhaps it would be more "lean" to just start with a wiki page (or
document) for alternative / better partitioning layouts, and when that has
stabilized then we can talk about Handbook integration, not?

Wkr,
Sven Vermeulen

Re: [gentoo-dev] Happy 10th birthday (in advance)

[Ciaran McCreesh]

On Fri, 30 Mar 2012 17:55:27 -0400
Richard Yao  wrote:
> I think we should wait for Portage 2.2 to be stabilized before we
> declare Gentoo 2.0. @preserved-libs is enough of an advance that I
> think claiming 2.0 would be merited, if only for the attention it
> would draw at Phoronix.

Do you really want to be advertising an awful hack that doesn't really
work, is conceptually unsound and that breaks all kinds of things in
subtle ways?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: location of portage tree

[Graham Murray]

"Walter Dnes"  writes:

> On Thu, Mar 29, 2012 at 10:26:22PM +1300, Kent Fredric wrote
>
>> Though of course, if anybody has custom stuff in say, /usr/portage/local/
>> which they make by hand, nuking /usr/portage will make you *Very*
>> unpopular.
>
>   
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part3_chap5
> in the install handbook gives "/usr/local/portage" as an example overlay
> directory.  I thought it was implicit that one shouldn't edit or create
> files in /usr/portage because they may be overwritten by the system e.g.
> during an "emerge --sync".  Maybe the manual needs to state this
> explicitly.  Also, /usr/local is the "standard" place to keep one's own
> software and/or global customizations that aren't handled by the package
> manager, but don't belong in one user's home directory.

Where using /usr/portage/local is useful is for 'site local'
packages. Where one system syncs externally and also has all of the
locally generated/edited packages in /usr/portage/local, and the other
systems share this site local repository simply by running "emerge
--sync" to the 'master' system.

[gentoo-dev] Re: rfc: location of portage tree

[Duncan]

Walter Dnes posted on Fri, 30 Mar 2012 00:08:08 -0400 as excerpted:

> On Thu, Mar 29, 2012 at 10:26:22PM +1300, Kent Fredric wrote
> 
>> Though of course, if anybody has custom stuff in say,
>> /usr/portage/local/
>> which they make by hand, nuking /usr/portage will make you *Very*
>> unpopular.
> 
>   http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?
full=1#book_part3_chap5
> in the install handbook gives "/usr/local/portage" as an example overlay
> directory.  I thought it was implicit that one shouldn't edit or create
> files in /usr/portage because they may be overwritten by the system e.g.
> during an "emerge --sync".  Maybe the manual needs to state this
> explicitly.  Also, /usr/local is the "standard" place to keep one's own
> software and/or global customizations that aren't handled by the package
> manager, but don't belong in one user's home directory.

FWIW:

$>>grep PORTDIR\\\|DISTDIR /etc/portage/make/fs
PORTDIR=/p
PORTDIR_OVERLAY=/l/p
DISTDIR=${PORTDIR}/src

$>>grep exclude /etc/portage/make/net$>>cat /etc/portage/make/
rsync.exclude 
# / on the left anchors (like regex ^), / on the right indicates dirs only

/layman/
/src/
/use.defaults

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from='/etc/portage/make/
rsync.exclude'"

$>>cat /etc/portage/make/rsync.exclude 
# / on the left anchors (like regex ^), / on the right indicates dirs only

/layman/
/src/
/use.defaults

--

(/etc/portage/make/fs and the corresponding net file are sourced by
/etc/portage/make/master, which in turn is sourced by /etc/make.conf, so 
those settings appear in portage, even tho they're actually in files in a 
particular subdir of /etc/portage.)

So I have PORTDIR set to /p, with the layman and src subdirs in it, and 
portage's rsync command set to exclude those subdirs.

FWIW, /usr/portage is a symlink to /p, just in case.

As Kent said, if that arrangement gets nuked despite my rsync --exclude 
settings, the person responsible certainly won't be particularly popular 
here (tho nothing irreplaceable would be lost, here, I'd simply have to 
adjust things and try again).

Fortunately, our portage devs appear to be a bit more sane than to try 
that and Zac at least isn't even proposing it.  His proposal is to simply 
change the default location for new users, which is fine by me. =:^)

-- 
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