Vaeth wrote:
Ciaran McCreesh wrote:
Having to write an ebuild just to install something in a package manager
friendly way and be able to uninstall it cleanly later is a defect
No, this is exactly what ebuilds meant for: That the package manager
keeps track of your package, and possibly also re
Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
Hi everyone
I'd like to bring bug #229521 to your attention and see whether we can
come up with a solution for it.
The problem:
A package "foo" depen
Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
Hi everyone
I'd like to bring bug #229521 to your attention and see whether we can
come up with a solution for it.
The problem:
A package "foo" depends on a slotted package "bar" _and_ more t
Tiziano Müller schrieb:
Hi everyone
I'd like to bring bug #229521 to your attention and see whether we can
come up with a solution for it.
The problem:
A package "foo" depends on a slotted package "bar" _and_ more than one
slot of "bar" can satisfy this dependency.
Why this is a problem:
If th
Benedikt Morbach schrieb:
++
I'm a user too and I really find it annoying that one can't read this
list to keep up with recent development, without digging to tons of
FUD, insults and other crap.
I personally came to the conclusion that it is best to simply ignore
all mails from certain people (
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 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
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 a
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 a
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
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
Luca Barbato schrieb:
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, maj
Patrick Lauer schrieb:
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, maj
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick unit tests would catch strai
Joe Peterson schrieb:
Bernd Steinhauser wrote:
And that is, what this is about, making EAPI bumps as less painful as
possible. The filename is the easiest solution for that.
In any design, there are "easy" short-cuts that can be taken. But
sometimes these short-cuts break paradigm
Luca Barbato schrieb:
Piotr Jaroszyński wrote:
The simplest way is to change the syncpoint in the new package
manager and
leave the previous uri with a compatibility repo for the older ones.
So we add a new repo each time a new EAPI comes out? Sounds like a big
mess.
It isn't you just keep
Joe Peterson schrieb:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson <[EMAIL PROTECTED]> wrote:
Well, in general, if you rely on extensions changing every time a
program cannot deal with a new feature of a file format, it would be
quite crazy. For example, if C programs
Ciaran McCreesh schrieb:
What all are blocks used for?
a) Marking that two unrelated packages are mutually incompatible at
runtime because they happen to collide, for example on a commonly named
executable.
b) Marking that two related implementations are mutually incompatible at
runtime because
Petteri Räty schrieb:
solar reported that he had ebuild submissions blindly using EAPI=1 so
we hopefully made the text better reflect that it should not be used
unless absolutely needed.
Regards,
Petteri
# Eclasses will test for this variable if they need to use EAPI > 0 features.
-# Ebuilds
Duncan schrieb:
Bernd Steinhauser <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Sat, 01 Mar
2008 23:50:09 +0100:
What about the timezone?
Baselayout had a setting for the timezone in /etc/conf.d/clock.
baselayout-2.0.0
+ openrc doesn't seem to have that.
Roy Marples schrieb:
On Friday 29 February 2008 16:15:51 Ed W wrote:
On the other hand since there still isn't a masked ebuild in portage
(and I seem some notes on my on Roy's site) then I have to assume that
in fact we are still a good way away from calling it a replacement and
starting to p
Santiago M. Mola schrieb:
I splitted this from the SoC thread so the possible discussion doesn't
add noise to the original thread.
On Tue, Feb 26, 2008 at 7:32 PM, joshua jackson <[EMAIL PROTECTED]> wrote:
Google is once again doing the summer of code for students. I'm helping
organize it
Fabian Groffen schrieb:
Though, if for instance amd64-fbsd would be introduced,
Will that happen? (Asking because I might be interested in testing such
a setup.)
I think this keyword should have something more generic arch instead, like
the x64 we use in prefix now
Wouldn't it be more cle
Doug Klima schrieb:
>> 2) ESVN_OFFLINE which disables svn up.
>
> Isn't this a bit of a hack? The point is for it to run svn up. Now
> I've added support in a local refactor that I had started today that
> if the working copy's revision matches the requested revision, that no
> svn up is performed.
Donnie Berkholz schrieb:
> On 23:39 Fri 15 Feb , Bo Ørsted Andresen wrote:
>> For quite a while the KDE herd has had a modified version of
>> subversion.eclass
>> in the kde overlay. During that time we have added the following
>> features to
>> the eclass which we would like to put back in gentoo-
Ryan Hill schrieb:
> Bernd Steinhauser wrote:
>> I'm aware of the fact, that the revision of the currently installed
>> package is part of the environment and that is saved, but I'm not only
>> interested in the revision of the currently installed version, but
Mike Frysinger schrieb:
> On Friday 11 January 2008, Bernd Steinhauser wrote:
>> this is sth.
>
> reading your e-mail drove me nuts as i cant figure out what "sth" means.
> google says "Sonic The Hedgehog". not sure how this applies to Gentoo (he's
Ryan Hill schrieb:
> Bernd Steinhauser wrote:
>> I'm aware of the fact, that the revision of the currently installed
>> package is part of the environment and that is saved, but I'm not only
>> interested in the revision of the currently installed version, but
Avuton Olrich schrieb:
> On 1/11/08, Bernd Steinhauser <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> this is sth. that has been brought up in the KDE4 forums thread and on
>> irc. The thing is, that if you're using a live ebuild you might very
>> likely r
Hi,
this is sth. that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you
Hi,
What about sth. like this:
> fglrx - VIDEO_CARDS setting to build driver for fglrx video cards
fglrx - Build AMD's proprietary video driver for r300-r600 video cards
> nv - VIDEO_CARDS setting to build driver for nv video cards
nv - Open source driver for Nvidia cards, only supports 2D
(I don
Hi,
I was searching a bit through bugzilla for some ebuilds for programs,
that are not yet in portage and I found, there are a lot of programs
hanging in buzilla, because no one did take them for maintenance.
Now some of them are quite old (no comments/activity for 2 years) and I
tried some of th
Gilles Dartiguelongue schrieb:
>> - net-wireless/rt2x00
> I might need this one for work, but it's not set in stone yet so if
> anybody has the hardware, please pick this one up.
>
rt2x00 will be introduced in kernel 2.6.24, so that package might be
deprecated then.
Bernd
--
[EMAIL PROTECTED]
34 matches
Mail list logo