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 see
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,
which is why
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 see any
В Сбт, 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
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
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 would be
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)
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 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
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 getting
too
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 information
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 to
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 next
Santiago M. Mola [EMAIL PROTECTED] writes:
* media-sound/amarok: live version is 1.4.. Next version is 2.0,
but that's a different branch so I'd expect 2.0.live to give me the
latest 2.0 version available, not 1.4's.
1.4. has been switched from because of the 2.0/1.4 branches,
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.
*
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
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
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 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 vote the other
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
On Sat, 14 Jun 2008 14:01:15 +0100
Ciaran McCreesh [EMAIL PROTECTED] 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
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 term
On Sat, 14 Jun 2008 12:32:22 +
Patrick Lauer [EMAIL PROTECTED] wrote:
Ok, here's a silly idea -
tag the ebuilds with metadata. We already have RESTRICT, why not add
a LIVE variable. The package manager can then treat all ebuilds
with that tag differently. Scripts can find them easily.
Ryan Hill [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Sat, 14
Jun 2008 09:04:26 -0600:
Having a method that
lets the user choose that the PM should check the scm tree and update
the package if there's a new revision would be even better.
I think that can be easily
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
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
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
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
--
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
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
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 have
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 upstream
On Sat, 14 Jun 2008 18:34:21 +0200
Bernd Steinhauser [EMAIL PROTECTED] wrote:
Ryan Hill schrieb:
No, the idea behind ESCM_LOGDIR was different.
If you just want the revision of the current installed thing, you can
grep through the environment.
ESCM_LOGDIR mainly aimed to provide a history
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
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
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
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 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
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
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 at
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.org mailing
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
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
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
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
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
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would
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 incorrectly
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
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
(trivial for
Peter Weller wrote:
On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote:
[snip]
I often don't agree with him, but can't help but respect the work he
does.
I would like to see Council move towards a more compressed meeting
format -- people presenting arguments need to work out their
Piotr Jaroszy?ski wrote:
Hello,
looks like every nominee wants the council to be more technical so I
have a few technical questions for you:
1. GLEP54
Doit!
2. GLEP55
Good idea. But the GLEP still contains too many may's and should's.
Example: [...] but note that one should never
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 version
54 matches
Mail list logo
