On Tue, 25 Apr 2006 20:03:00 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
I'd like to see some clarification of intended doc use flag usage
From what I've gleaned over time, USE=doc is supposed to enable docs
that are one or more of:
(1) large
(2) take a significant amount of resource to build
(3)
Jakub Moc posted [EMAIL PROTECTED], excerpted below, on Tue,
25 Apr 2006 20:03:00 +0200:
I'd like to see some clarification of intended doc use flag usage, so that
we wouldn't force users to download/install 40+ megs of docs for a ~3 meg
package, with the only reason being that USE=doc is for
Pasted from bugzilla. Please pardon the ugly newline formatting.
I'm a longtime (10 yrs) Linux admin and I've been using Gentoo for
perhaps 2
years and I'm super impressed with Gentoo, having gotten very annoyed
with the
rpm-based nightmare upgrade situation presented by most of the other
On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote:
One thing that I'm pretty sure is currently not possible with portage,
however, and that I'd definitely like to see as a part of this idea is a
way of setting thresholds on version numbers of packages in portage such
that the automated upgrade
Chris Gianelloni wrote:
On Wed, 2006-04-26 at 12:29 -0400, Kevin wrote:
One thing that I'm pretty sure is currently not possible with portage,
however, and that I'd definitely like to see as a part of this idea is a
way of setting thresholds on version numbers of packages in portage such
that
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
What I really want is to make the process of maintaining Gentoo boxes
over the long term easier (IOW: less time-consuming) than is now true,
by adding some functionality that AFAICT does not now exist which would
allow me to automate some things,
On Wed, 2006-04-26 at 14:24 -0400, Kevin wrote:
And unless I'm way off-base, the version-difference-threshold notion
described above is not implemented in portage now. Someone please
correct me if I'm wrong.
You're off-base.
See, you can, for example, mask all revisions within the same
Jean-Francois Gagnon Laporte wrote:
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
What I really want is to make the process of maintaining Gentoo boxes
over the long term easier (IOW: less time-consuming) than is now true,
by adding some functionality that AFAICT does not now exist which would
Chris Gianelloni wrote:
Honestly, I don't see portage ever being able to really
support anything like this so long as the tree continues to change.
It simply doesn't seem to be compatible with how Gentoo development is
done.
and Chris Gianelloni wrote:
Yup. It's called
zing !
and with this post it's probably best to let this subthread die before we get
any more offtrack
-mike
--
gentoo-dev@gentoo.org mailing list
On Wed, 2006-04-26 at 15:55 -0400, Kevin wrote:
Which is it, Chris?
You've taken that out of context ...
Make up your mind...
I think he has, but wasn't able to communicate his ideas to you in an adequte
way
For all the credit that I give to the Gentoo developers, you are one
from whom I
On Wed, 26 Apr 2006 15:30:35 -0400, Kevin wrote:
Jean-Francois Gagnon Laporte wrote:
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
What I really want is to make the process of maintaining Gentoo boxes
over the long term easier (IOW: less time-consuming) than is now true,
by adding some
Thanks for your informative reply, Peter. I think I'll try your method
for awhile. I'm sure it's less time consuming than my current method,
if perhaps still not ideal, and although I do realize this idea may be
an unattainable utopia, by Jean-Francois pointing me to glcu, I'm glad
to see that
Chris Gianelloni posted [EMAIL PROTECTED],
excerpted below, on Wed, 26 Apr 2006 15:27:38 -0400:
I'm sorry, but do your friends call you Duncan? I'll leave it at that.
Who, me? looks around No, safe to say, /not/ me.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program
Hi All,
Consider this both a rant and a GLEP pre-proposal. When we created the
idea of herds back in the day, there was a clear distinction between a
herd and a team (and a project). Over time, those definitions have
become blurry. I would like emphasise:
A herd is a group of like *packages*
Seemant Kulleen [EMAIL PROTECTED] said:
Consider this both a rant and a GLEP pre-proposal. When we created the
idea of herds back in the day, there was a clear distinction between a
herd and a team (and a project). Over time, those definitions have
become blurry. I would like emphasise:
Is there a reason for this besides the definitions not falling into
place as they should? I'm not seeing a benefit from this to be honest.
People refer to teams as herds a lot of the time. It has become a
statement over time that people understand. I'm not sure why we want to
try and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seemant Kulleen wrote:
Is there a reason for this besides the definitions not falling into
place as they should? I'm not seeing a benefit from this to be honest.
People refer to teams as herds a lot of the time. It has become a
statement over
Daniel Goller wrote:
I like the idea. (But i guess you figured that out already ;)
To make it easy, we could just s/herd/team/.
Donnie
--
gentoo-dev@gentoo.org mailing list
On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote:
Daniel Goller wrote:
I like the idea. (But i guess you figured that out already ;)
To make it easy, we could just s/herd/team/.
then you might as well just keep herd and discard team altogether
-mike
--
gentoo-dev@gentoo.org mailing
Hello fellow developers,
It's that time of the insert whatever works for you here where I send
off an email reminding people on what not to do when bumping versions
of packages when it comes to keywords.
1) Please do not drop arch keywords without notifying the arch teams of
why (bugs are
Mike Frysinger wrote:
On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote:
Daniel Goller wrote:
I like the idea. (But i guess you figured that out already ;)
To make it easy, we could just s/herd/team/.
then you might as well just keep herd and discard team altogether
Yeah, pretty
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
I'd like to have the capability of being able to list some packages that
should
never be upgraded automatically (I realize I can do this to some degree
already
with portage), some others that are very unlikely to break from an automated
upgrade
James Potts wrote:
-fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's
filtered now),
Again, probably -fvisibility=hidden. Many people have had success building KDE
with both flags enabled lately, so maybe that's something that could be
revisited when 4.1 goes
24 matches
Mail list logo
