On Mon, 10 Dec 2007 13:14:56 +0530
Nirbheek Chauhan [EMAIL PROTECTED] wrote:
On Dec 10, 2007 12:48 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
Feature as opposed to release branches would still have to be
separate packages, especially if you need to depend upon a
particular feature.
I
On Mon, Dec 10, 2007 at 07:18:26AM +, Ciaran McCreesh wrote:
On Sun, 9 Dec 2007 20:31:46 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 18:57 Sun 09 Dec , Ciaran McCreesh wrote:
On Sun, 09 Dec 2007 19:45:27 +0100
Jan Kundr??t [EMAIL PROTECTED] wrote:
What is the point of
On Mon, 10 Dec 2007 00:26:21 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
There's two cases of branches I see (irrelevant of the names used):
Major version branches - eg CVS cvs-1.11.x and cvs-1.12.x
(those are the actual upstream branch names, I've seen other packages
using the branch
On Mon, Dec 10, 2007 at 08:24:27AM +, Ciaran McCreesh wrote:
mypkg-scm
One devil's advocate question for now.
Regardless of which suffix we pick, given that it is a well-known
suffix, what will be the expected behavior when PN = 'foo-scm'?
There's at least one package on Freshmeat with
On Mon, 10 Dec 2007 00:36:04 -0800
Robin H. Johnson [EMAIL PROTECTED] wrote:
On Mon, Dec 10, 2007 at 08:24:27AM +, Ciaran McCreesh wrote:
mypkg-scm
One devil's advocate question for now.
Regardless of which suffix we pick, given that it is a well-known
suffix, what will be the
On 00:26 Mon 10 Dec , Robin H. Johnson wrote:
What I've got for my Xorg testing setup, is foo--rX, with a number
of different -X values that I just select from via package.{un,}mask
while testing - this saves altering everything else in the tree to pick
some package that has a
On Dec 10, 2007 10:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 00:26 Mon 10 Dec , Robin H. Johnson wrote:
What I've got for my Xorg testing setup, is foo--rX, with a number
of different -X values that I just select from via package.{un,}mask
while testing - this saves
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
Why not just have something like
sys-devel/gcc-4.2.3_p20071127-scm_b${BRANCHNAME}-r1 ?
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
2) It will break updating
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
Why not have them block each other such that only one branch can be
installed at a time? There can
On Monday, 10. December 2007, Nirbheek Chauhan wrote:
On Dec 10, 2007 6:29 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
1) You cannot define a total order on those names:
Is
maa/moo-3-scm_bONECOOLFEATURE
maa/moo-3-scm_bOTHERCOOLFEATURE
?
Why not have them block each other
On 10:34 Mon 10 Dec , Santiago M. Mola wrote:
On Dec 10, 2007 10:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 00:26 Mon 10 Dec , Robin H. Johnson wrote:
What I've got for my Xorg testing setup, is foo--rX, with a number
of different -X values that I just select from via
On Dec 10, 2007 8:44 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
That would still mean everything relies on n ebuilds with mutual blocks.
Even if that would work and it block upgrades, it is still not a
solution in terms of how to display a list of ebuilds in one tree in an
ordered list.
The
On Dec 11, 2007 1:14 AM, Nirbheek Chauhan [EMAIL PROTECTED] wrote:
Of course this could be extended to apply only to branch ebuilds
without a version number (where you know when the branch will be
merged), etc.
s/you know/you don't know/
--
~Nirbheek Chauhan
--
[EMAIL PROTECTED] mailing
Doug Klima wrote:
Hello all,
Currently our Heimdal packages and MIT-KRB5 packages are woefully out of
date. I know Seemant tried for a while and I have been trying to recruit
maintainers for these packages but completely unsuccessfully. So I turn
to the mailing list to hopefully recruit
Donnie Berkholz wrote:
vmmouse input driver (For X inside VMWare)
vmware (For X inside VMWare)
I can take those two if nobody else wants them.
--
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility: Samba, PostgreSQL, cpp, Python
E-Mail : [EMAIL PROTECTED]
GnuPG FP : F327
On 09:42 Mon 10 Dec , Bjarke Istrup Pedersen (gurligebis) wrote:
1.1 net-wireless/hostapd/hostapd-0.6.1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-wireless/hostapd/hostapd-0.6.1.ebuild?rev=1.1view=markup
plain:
On 22:07 Mon 10 Dec , Tiziano Müller wrote:
Donnie Berkholz wrote:
vmmouse input driver (For X inside VMWare)
vmware (For X inside VMWare)
I can take those two if nobody else wants them.
They're all yours. Thanks! The nice thing about them is that there
aren't any open bugs. It's
Nirbheek Chauhan wrote:
On Dec 10, 2007 8:44 PM, Robert Buchholz [EMAIL PROTECTED] wrote:
That would still mean everything relies on n ebuilds with mutual blocks.
Even if that would work and it block upgrades, it is still not a
solution in terms of how to display a list of ebuilds in one tree
Ciaran McCreesh wrote:
Incidentally, I suspect the gcc example with _p is confusing people. The
normal use for an -scm suffix will be as follows:
Yeah I abused the _p suffix. My bad.
The whole _p thing only comes up for those very rare (or possibly
non-existent) projects that have patchset
Donnie Berkholz wrote:
On 10:34 Mon 10 Dec , Santiago M. Mola wrote:
On Dec 10, 2007 10:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
While we're getting a bit off the original topic here, it occurred to me
that using SLOTs for this, in combination with various SLOT deps and
SLOT
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF ${CONFIG}
...
CONFIG_EAP_SAKE=y
...
EOF
-mike
signature.asc
Description: This is a digitally signed message part.
21 matches
Mail list logo
