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
On Thu, 2008-06-12 at 11:39 +0200, Fernando J. Pereda wrote:
On 12 Jun 2008, at 04:16, Brian Harring wrote:
Why the exherbo/paludis/PMS folk decided to go this route to report,
I'm not quite sure aside from assuming they're just griefers.
s-exherbo/paludis/PMS-pkgcore-g and:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What's the need for a GLEP covering live ebuilds and what's wrong with
- - ebuilds? I made myself that question when GLEP54 was submitted and
during the initial discussion. At that time, I wasn't convinced of the
need for such a GLEP. Now I think
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.
*
On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote:
What's the need for a GLEP covering live ebuilds and what's wrong with
- ebuilds? I made myself that question when GLEP54 was submitted and
during the initial discussion. At that time, I wasn't convinced of the
need for
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
Jorge Manuel B. S. Vicetto wrote:
Those using paludis need just to run[1]:
~ paludis -pi1 compiz-fusion --dl-reinstall-scm always --compact \
~--show-reasons none
and what about
# emerge @compiz [1]
Simpler isn't it?
Or
# emaint -r world[2]
# emerge -u compiz-fusion
[1] you you can
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 Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
That's what metadata is there for. And ebuilds don't mind carrying a bit
more ... after all it's just one line of text.
So, what you want to do is to read every ebuild, if you want to find all
live ebuilds?
Metadata cache. It's
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
Patrick Lauer schrieb:
On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
That's what metadata is there for. And ebuilds don't mind carrying a bit
more ... after all it's just one line of text.
So, what you want to do is to read every ebuild, if you want to find all
live ebuilds?
Patrick Lauer schrieb:
On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
That's what metadata is there for. And ebuilds don't mind carrying a bit
more ... after all it's just one line of text.
So, what you want to do is to read every ebuild, if you want to find all
live ebuilds?
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
Since some people have been asking about this... Here's how I'd see
upstream revision awareness being added to the -scm proposal.
* add src_fetch_extra or whatever to avoid doing the fetches in
src_unpack.
* add pkg_scm_info. It outputs a string containing no spaces.
* When installing an scm
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
Ciaran McCreesh wrote:
* add src_fetch_extra or whatever to avoid doing the fetches in
src_unpack.
good idea.
* add pkg_scm_info. It outputs a string containing no spaces.
.live would need something a bit different.
* When installing an scm package with suitable EAPI to VDB / exndbam,
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:30:59 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* When installing an scm package with suitable EAPI to VDB /
exndbam, rewrite the scm version to [EMAIL PROTECTED]
so -scm will have a @ metachar to point that what's following is the
hash/revision/reference to avoid
Hallo list,
I stumble across a nice problem:
At the moment i am creating the ebuilds for the Mandriva Management Console
(http://mds.mandriva.org).
the web Interface is php based so the webapp eclass would be the best way
but know the show stopper the webiterface supports plugins
so how can
could think of (and one I use constantly).
gcc is nice enough that i can do `gcc -v` and get
gcc version 4.3.2-pre20080612 built 20080614 (Gentoo SVN ebuild) rev.
136782 ()
but not everything works like that.
--
gcc-porting, by design, by neglect
treecleaner
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 Sat, 14 Jun 2008 10:38:18 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
Ignoring possible semantic issues for the moment,
Please point them so I could fix them properly ^^
For example all the ordering issues pointed out by others in this
thread. Also the whole
On Sat, 14 Jun 2008 12:32:22 +
Patrick Lauer [EMAIL PROTECTED] wrote:
Portage 2.2 and others support sets, portage 2.2 even supports
dynamic sets like the @preserved-rebuild. Shouldn't be that hard to
add a live-ebuilds dynamic set.
(Comments on the feasibility of my idea from portage
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
55 matches
Mail list logo
