* Kent Fredric [EMAIL PROTECTED] wrote:
Hi,
So, your suggesting the following would have been a better
option in this case
dev-lang/php4/php4-4.4.3.ebuild
dev-lang/php4/php4-4.4.4.ebuild
dev-lang/php5/php5-5.1.1.ebuild
dev-lang/php5/php5-5.2.0.ebuild
Yes.
virtual/php/php-5.ebuild -
* Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
Hi,
Wtf. Newer versions are newer versions. No matter if they are
fully backwards compatible or not.
I really don't aggree your really loose view of versions.
That's like seeing ISDN as an newer version of POTS.
Well, if you're convinced about
On 6/13/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
Okay, this isn't really about slots vs. no slots, but shows that
slots are not necessary.
cu
Well, IMO everything should be slotted 100% every version able to be
installed in parallel, and packages depend on version, and versions
with no
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
* Kent Fredric [EMAIL PROTECTED] wrote:
Ah, but you see, in half the cases there is not a /complete/
incompatibility. PHP4-5 migration is not an entirely big switch,
the biggest problem IIRC in the 4-5 change is the way it handles
classes,
On Friday 08 June 2007 14:46:54 Enrico Weigelt wrote:
Well, they still are different versions under the same packages
from the same projects.
Evolutionarily yes, technically no ;-P
They're in fact very diffrent, but provide an very similar
(almost the same) functionality.
The problem is:
On Saturday 09 June 2007 08:44:23 Kent Fredric wrote:
%=sys-devel/automake-1.9
%=sys-devel/automake-1.9
%=sys-devel/automake-1.9
Why that syntax ?
Well , we have a dilemour, if we were to change the way package atoms
were named, it would break /craploads/ of the stuff already available
* Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
Hi,
These are packages totally incompatible and so different
packages under the same name. They're sometimes necessary,
since certain projects still require very old version,
even if upgrade wouldn't be such a problem and has already
been
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
What flexibility do I take away exactly ?
And what exactly gets harder ?
Automated building of dependant packages
Gentoo has a collection of magic script that do make this nice for us.
ie ( last I looked anyway ) java-config and autoconf
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
* Kent Fredric [EMAIL PROTECTED] wrote:
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
What flexibility do I take away exactly ?
And what exactly gets harder ?
Automated building of dependant packages
More precisely ?
AFAICS it
* Kent Fredric [EMAIL PROTECTED] wrote:
On 6/9/07, Enrico Weigelt [EMAIL PROTECTED] wrote:
What flexibility do I take away exactly ?
And what exactly gets harder ?
Automated building of dependant packages
More precisely ?
AFAICS it would be much easier w/o slots.
I already mentioned
On 6/9/07, Kent Fredric [EMAIL PROTECTED] wrote:
On 6/9/07, Kent Fredric [EMAIL PROTECTED] wrote:
In the case of autoconf, im personally glad it all hides under one
non-linear space-time-continumum on my harddrive ;) . The thought of
them all being in seperate ebuild names would drive me
* Kent Fredric [EMAIL PROTECTED] wrote:
Ah, but you see, in half the cases there is not a /complete/
incompatibility. PHP4-5 migration is not an entirely big switch,
the biggest problem IIRC in the 4-5 change is the way it handles
classes, and a lot of code 'simply works' on both.
I had to
On Thursday 07 June 2007 01:44:39 Enrico Weigelt wrote:
Now... Why are there multiple versions of java-config,
autoconf, and automake shown on my system?
These are packages totally incompatible and so different
packages under the same name. They're sometimes necessary,
since certain
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
/usr/lib/lib-gnu-java-awt-peer-gtk.la)
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
/usr/lib/libgcj.la)
https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
--
Bo Andresen
Thanks, Bo -- editing the .la
HI...
On 31/05/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
--prune makes no checks of what's still required.
[SNIP]
But doesn't --prune just remove all but the most recent installation
of a given package?
Yes.
I knew there was a reason I followed a --prune up with a -DNuva
world as
Hi all...
This is the output of emerge --info for the Gentoo box that I'm
still configuring - fresh install. I configured and compiled a
working version of the kernel, configured CFLAGS and USE flags, etc.
I also ran emerge -eD system and emerge -eD world and updated /etc
configs accordingly.
On Wednesday 30 May 2007 21:23:00 Denis wrote:
Why are there multiple versions of java-config, autoconf, and
automake shown on my system?
They are incompatible, slotted, and each slot is individually required (or was
at some time).
There could be other multi-version
packages... Is this
Hi,
On 31/05/07, Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote:
There could be other multi-version
packages... Is this normal for portage that is configured to
autoclean?
Yes. Autoclean doesn't uninstall versions in a different slot. I'm not sure
about depclean.
I think what is more
On Thursday 31 May 2007 04:43:07 Boyd Stephen Smith Jr. wrote:
There could be other multi-version
packages... Is this normal for portage that is configured to
autoclean?
Yes. Autoclean doesn't uninstall versions in a different slot. I'm not
sure about depclean.
With the latest
On 5/30/07, Ric de France [EMAIL PROTECTED] wrote:
I think what is more useful is --prune (I'm guessing as I'm not in
front of a Gentoo box at the moment). I usually try:
# emerge -Pp
Here's the output:
myhost etc # emerge -Pp
These are the packages
On Thursday 31 May 2007 05:53:08 Denis wrote:
On 5/30/07, Ric de France [EMAIL PROTECTED] wrote:
I think what is more useful is --prune (I'm guessing as I'm not in
front of a Gentoo box at the moment). I usually try:
--prune makes no checks of what's still required.
[SNIP]
But doesn't
While on the subject, I ran a pretend on revdep-rebuild, and it's
complaining about some broken libraries in GCC...
[SNIP]
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
/usr/lib/lib-gnu-java-awt-peer-gtk.la)
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la
On Thursday 31 May 2007 06:25:58 Denis wrote:
While on the subject, I ran a pretend on revdep-rebuild, and it's
complaining about some broken libraries in GCC...
[SNIP]
broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
/usr/lib/lib-gnu-java-awt-peer-gtk.la)
23 matches
Mail list logo
