> 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
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 po
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 't
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
latest version you installed. ;)
It was the only example I 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,
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 i
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
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 upstre
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
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,
rew
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
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 pac
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
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 ca
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
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?
Meta
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?
Meta
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
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 give
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
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 hav
Patrick Lauer schrieb:
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 convi
On Fri, 13 Jun 2008 21:55:29 +0200
"Santiago M. Mola" <[EMAIL PROTECTED]> wrote:
> As discussed in bug #222721, portage has changed the execution order
> of phases. It seems the change was introduced in portage-2.1.5 and it
> makes that, when upgrading a package, pkg_postinst is run after the
> old
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.
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 do
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
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 f
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
"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 branch
-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 thin
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 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:
>
>
Marius Mauch wrote:
Ignoring possible semantic issues for the moment,
Please point them so I could fix them properly ^^
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 SVN, n
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
63 matches
Mail list logo
