On Tue, 17 Jun 2008 10:59:37 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> About glep-54:
>
> emerge code-scm
>
> what should fetch?
>
> (given that code is an editor and code-scm is a plugin adding scm
> support...)
code-scm. There is no way of distinguishing between a c/p and a c/p-v,
whic
Ryan Hill wrote:
On Sat, 14 Jun 2008 22:16:36 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Bernd Steinhauser wrote:
Wow, impressive.
Actually, you can't be serious...
I am.
GLEP 54 for quite some time now and it works very well.
adds nothing to - and sets usage as is.
I just don't se
В Сбт, 14/06/2008 в 19:28 +0200, Luca Barbato пишет:
> I don't see disadvantages, all I wanted is a simple way to archive this:
> [# emaint -r ffmpeg ... # emerge ffmpeg -L ... egen ... skipped most of stuff]
Your example shows that .live ebuilds "fix" different issue. What you
are suggesting are
> Using live templates is something more ^^;
For now it looks to me like it is only more work. Could you please
clarify what new functionality they provide?
--
Best Regards,
Piotr Jaroszyński
Fernando J. Pereda wrote:
On 14 Jun 2008, at 22:18, Luca Barbato wrote:
mainline glibc usually requires you to fix it or the rest of the world...
What?
I experienced that the hard way -_-
(btw they are single packages, emerge =python- works as should)
So what was your proposal all abo
On 14 Jun 2008, at 22:18, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 20:02, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after
every 4.1.x rel
Fernando J. Pereda wrote:
On 14 Jun 2008, at 20:02, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enfor
Bernd Steinhauser wrote:
Wow, impressive.
Actually, you can't be serious...
I am.
GLEP 54 for quite some time now and it works very well.
adds nothing to - and sets usage as is.
I just don't see any benefit from your proposal, on the contrary there
are issues.
No.
And that includes
> > emerge -C @kde-svn
> >
> > emerge @kde-svn
> >
> > that should suffice.
>
> I don't see that working for something like, say, python or glibc.
No need, emerge @kde-svn will re-merge all packages in the set by default. So
unmerging isn't needed and it just works.
--
gentoo-dev@lists.gentoo.
Ryan Hill wrote:
> (...I would change the suffix to -live, just because i
> hate the term "SCM" :P)
++ on using "live" and not the "scm" acronym (no matter which idea is
selected), especially since there are various different acronyms for
config mgmt (scm, cm...), and scm's meaning is less obvious
Luca Barbato schrieb:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep in mind that -, -scm ebuild or .live templates
a
On 14 Jun 2008, at 20:02, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after
every 4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep in mind that -, -scm
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep in mind that -, -scm ebuild or .live templates
aren't for public consum
Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has
absolutely no correlation with the revision number of the
Ryan Hill schrieb:
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do I h
Luca Barbato schrieb:
Bernd Steinhauser wrote:
In the -scm approach this means:
trunk = -scm
4.1 branch = -4.1-scm
so you'll be oblivious of changes needed inside the ebuild and you won't
know what you merged last time you issued an emerge =foo-scm (that by
itself it is a problem, since it i
On 14 Jun 2008, at 18:23, Luca Barbato wrote:
Fernando J. Pereda wrote:
nope it would resolve as foo_pre1 -> meaningless.
So your proposal is unable to handle that case, right?
You are forced to put a version, that's all.
Which doesn't always make sense so we are back to 9 version
Fernando J. Pereda wrote:
nope it would resolve as foo_pre1 -> meaningless.
So your proposal is unable to handle that case, right?
You are forced to put a version, that's all.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lis
On 14 Jun 2008, at 18:03, Luca Barbato wrote:
trunk = .live
nope it would resolve as foo_pre1 -> meaningless.
So your proposal is unable to handle that case, right?
- ferdy
--
gentoo-dev@lists.gentoo.org mailing list
Bernd Steinhauser wrote:
MPlayer has a psychological issue with 1.0 versioning, still 1.0.live
correctly isn't higher than 1.0
No, it is not.
For mplayer it is correct. I'm MPlayer upstream as well. I do know.
In the -scm approach this means:
trunk = -scm
4.1 branch = -4.1-scm
so you'll be
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has absolutely
no correlation with the revision number of the upstream codebase. I'm
sorry, but that's unacceptable. :/
You'd like to have the cflags and
On Sat, 14 Jun 2008 08:45:08 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:
> Just curious, were you happy with the previous GLEP54 draft or were
> there still issues that had to be addressed? As far as I'm concerned
> it's fine. (though I would change the suffix to -live, just because i
> hate the t
Luca Barbato schrieb:
Santiago M. Mola wrote:
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]>
wrote:
Ryan Hill wrote:
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released. I already need to do this with my live ebuilds. Of
course, with
On Sat, 14 Jun 2008 15:29:00 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Which of the issues I listed needs to be addressed for the scm
> > proposal?
>
> At least the upstream server load.
-scm doesn't attempt to use upstream to obtain any information.
Upstream is o
On Sat, 14 Jun 2008 15:25:53 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > * What generation looks like.
>
> Mostly implementation detail? Somebody seems to have ideas there and
> I like to heard ideas from others as well.
It's not a detail. It's extremely important,
Ciaran McCreesh wrote:
Which of the issues I listed needs to be addressed for the scm proposal?
At least the upstream server load.
Ok, here's the best help I can give you: Your proposal can't work. You
can't get correct ordering reusing existing components. You can't get
sane behaviour using
Ciaran McCreesh wrote:
* What generation looks like.
Mostly implementation detail? Somebody seems to have ideas there and I
like to heard ideas from others as well.
* How to select which ebuilds to trigger generation for.
I'm fond of sets and I'd extend maint to be feeded to sets other th
On Sat, 14 Jun 2008 15:15:45 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 14:27:22 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Many of them applies as well to the alternative proposal, I wonder
> >> how you could say we, council, had to v
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 14:27:22 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Many of them applies as well to the alternative proposal, I wonder
how you could say we, council, had to vote the other proposal given
such (and other) issues were open.
No they don't.
False.
On Sat, 14 Jun 2008 14:27:22 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Many of them applies as well to the alternative proposal, I wonder
> how you could say we, council, had to vote the other proposal given
> such (and other) issues were open.
No they don't. The alternative proposal is deli
Santiago M. Mola wrote:
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote:
Ryan Hill wrote:
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released. I already need to do this with my live ebuilds. Of
course, with some projects you never
Ciaran McCreesh wrote:
* What generation looks like.
* How to select which ebuilds to trigger generation for.
* When specifically to trigger generation.
* Whether generation failure is possible, and what happens if it is.
* What to do when generated information is required but not available.
* Th
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ryan Hill wrote:
>>
>> I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
>> 0.26 was released. I already need to do this with my live ebuilds. Of
>> course, with some projects you never know if the n
On Sat, 14 Jun 2008 12:45:31 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > And none of those are even close to a reasonable, implementable
> > idea.
>
> They are implementable.
They're really not. You haven't even begun to discuss:
* What generation looks like.
* How to select which ebuilds
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 12:04:45 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
It will be available once you trigger again the generation or if
you put a normal ebuild with such name.
And what triggers said generation?
I already replied in this thread, I guess the informatio
On Sat, 14 Jun 2008 12:04:45 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> It will be available once you trigger again the generation or if
> >> you put a normal ebuild with such name.
> >
> > And what triggers said generation?
>
> I already replied in this thread, I guess the information is
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 14 Jun 2008 10:19:32 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >>> I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
> >>> rev. 136737, after the merge do I have
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do I have gcc-4.4.0_pre136737
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
installe
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> > I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
> > rev. 136737, after the merge do I have gcc-4.4.0_pre136737
> > or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc)
> > installed?
>
> it
Ryan Hill wrote:
On Fri, 13 Jun 2008 13:35:52 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:
Ignoring possible semantic issues for the moment, I'd be against this
simply because it would require the PM to be aware of the current
revision of the repository and to transform it into a integer value
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild with the version mentioned and _preN+1 postponed,
preN is
On Fri, 13 Jun 2008 11:14:49 +0200
Tiziano Müller <[EMAIL PROTECTED]> wrote:
> > How does your proposal handle this?
>
> s/_pre/_p ?
Collides with existing use of _p. It means you can't use _p for manual
snapshots if there's also a live ebuild, since foo-1.2_p3 (from a live
ebuild) would incorrec
On Mon, 09 Jun 2008 09:45:37 +0200
Tiziano Müller <[EMAIL PROTECTED]> wrote:
> And why don't we change the versioning of the EAPI to a "X.Y" scheme
> and demand that changes in the minor version must not break sourcing
> of the ebuild with older package managers and that major versions do.
> Major
46 matches
Mail list logo
