Am 17.05.2007 um 22:58 schrieb Stephen Montgomery-Smith:
Stephen Montgomery-Smith wrote:
Alexander Leidinger wrote:
As portupgrade cleans before and after updating a
port, optimizing this may also be beneficial.
Maybe first trying to construct all dependencies of the installed
ports
like
Stephen Montgomery-Smith wrote:
Alexander Leidinger wrote:
Quoting Robert Noland [EMAIL PROTECTED] (Wed, 16 May 2007 18:14:01
-0400):
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
On Sat, 19 May 2007, Garrett Cooper wrote:
My lord.. now I see what everyone means in terms of taking a long
time to update the ports / package databases. If you use portsnap, it doesn't
take a long time. However, if you use csup/cvsup, it appears to take a long
time running make and ruby
Stephen Montgomery-Smith wrote:
On Sat, 19 May 2007, Garrett Cooper wrote:
My lord.. now I see what everyone means in terms of taking a long
time to update the ports / package databases. If you use portsnap, it
doesn't take a long time. However, if you use csup/cvsup, it appears
to
On Sat, 19 May 2007, Garrett Cooper wrote:
Stephen Montgomery-Smith wrote:
On Sat, 19 May 2007, Garrett Cooper wrote:
Don't try. portupgrade is maintained by someone else, and the scripts are a
mess.
If someone could have improved the scripts, they would have tried a while
ago..
oh
Quoting Robert Noland [EMAIL PROTECTED] (Wed, 16 May 2007 18:14:01 -0400):
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates are the real dependencies on
Quoting Alexander Leidinger [EMAIL PROTECTED] (Thu, 17 May 2007 11:44:36
+0200):
For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time (interesting is the user
Alexander Leidinger wrote:
Quoting Robert Noland [EMAIL PROTECTED] (Wed, 16 May 2007 18:14:01 -0400):
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates are the
Alexander Leidinger wrote:
Quoting Alexander Leidinger [EMAIL PROTECTED] (Thu, 17 May 2007 11:44:36
+0200):
For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Thu, 17 May 2007 08:14:43
-0500):
Alexander Leidinger wrote:
Quoting Alexander Leidinger [EMAIL PROTECTED] (Thu, 17 May 2007 11:44:36
+0200):
For the difference between the redirected output case: I think the
gnome terminal needs a
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed, 16 May 2007 16:01:56
-0500):
If I get some positive feedback on this one, I'll submit a PR. You can
try it out by typing make actual-package-depends as opposed to make
package-depends.
Did you my chance also had a look how to speed
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from
Thu, 17 May 2007 15:58:38 -0500):
Stephen Montgomery-Smith wrote:
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed,
16 May 2007 16:01:56 -0500):
If I get some positive feedback on this one, I'll
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from
Tue, 15 May 2007 16:53:35 -0500):
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
2. Sorting the dependencies in pkg_create. My fix now cuts this
out completely. Thus there is no need to change the structure of
On Wed, May 16, 2007 at 10:13:41AM +0200 I heard the voice of
Ulrich Spoerlein, and lo! it spake thus:
True, true. And as pointed out above, if you don't build the INDEX
with your current pkg options, it is useless anyway.
Oh, worse. If you don't build INDEX with your current _installed
On 5/16/07, Matthew D. Fuller [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 10:13:41AM +0200 I heard the voice of
Ulrich Spoerlein, and lo! it spake thus:
True, true. And as pointed out above, if you don't build the INDEX
with your current pkg options, it is useless anyway.
Oh, worse. If
What I don't like about the flattening of the dependencies is
that there seems to be information loss; that is, I can't figure
out why one port (e.g., gweled) requires another port (e.g.,
cdrtools). Is there any tool to unflatten the dependencies?
--
J. Porter Clark [EMAIL PROTECTED]
Quoting J. Porter Clark [EMAIL PROTECTED] (from Wed, 16 May 2007
06:25:32 -0500):
What I don't like about the flattening of the dependencies is
that there seems to be information loss; that is, I can't figure
out why one port (e.g., gweled) requires another port (e.g.,
cdrtools). Is there
Ulrich Spoerlein wrote:
On 5/15/07, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote:
Ulrich Spoerlein wrote:
I also need to quickly look up origin - pkgname and would suggest
placing this in the INDEX file. Then you have the foundation in
place to
be able to run 'make vim-7.1.2.tbz' in,
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a
very
significant way to
On 5/16/07, Alexander Leidinger [EMAIL PROTECTED] wrote:
Quoting J. Porter Clark [EMAIL PROTECTED] (from Wed, 16 May 2007
06:25:32 -0500):
What I don't like about the flattening of the dependencies is
that there seems to be information loss; that is, I can't figure
out why one port (e.g.,
Quoting Ulrich Spoerlein [EMAIL PROTECTED] (Wed, 16 May 2007 18:28:55
+0200):
The problem not discussed so far is: some ports may not have all first
order dependencies. So anyone wanting to change this should install a
tinderbox and start testing fixing those ports.
Hmmm, this is a red
Alexander Leidinger wrote:
Quoting Ulrich Spoerlein [EMAIL PROTECTED] (Wed, 16 May 2007 18:28:55
+0200):
The problem not discussed so far is: some ports may not have all first
order dependencies. So anyone wanting to change this should install a
tinderbox and start testing fixing those
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (Wed, 16 May 2007 07:59:11
-0500):
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from Tue,
15 May 2007 16:53:35 -0500):
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the dependencies
it creates are the real dependencies on your system, not what ports
thinks it should be, because it gets all the information from
/var/db/pkg. On my system it takes a second or two to
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates are the real dependencies on your system, not what ports
thinks it should be, because it gets all the
Robert Noland wrote:
On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
Ok chaps, I think I have it.
This involves no recursive calls of make. Furthermore the
dependencies
it creates are the real dependencies on your system, not what ports
thinks it should be, because it
Stephen Montgomery-Smith píše v po 14. 05. 2007 v 09:39 -0500:
Someone pointed out that what I was proposing in +DEPENDENCIES is
already to be found in +CONTENTS. So here is a proof of concept patch
to /usr/ports/Mk/bsd.port.mk (proof of concept because no error
checking, and things like
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v po 14. 05. 2007 v 09:39 -0500:
Someone pointed out that what I was proposing in +DEPENDENCIES is
already to be found in +CONTENTS. So here is a proof of concept patch
to /usr/ports/Mk/bsd.port.mk (proof of concept because no error
Stephen Montgomery-Smith wrote:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v po 14. 05. 2007 v 09:39 -0500:
Someone pointed out that what I was proposing in +DEPENDENCIES is
already to be found in +CONTENTS. So here is a proof of concept
patch to /usr/ports/Mk/bsd.port.mk (proof of
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
And also, the only reason it goes slow is because it has to do
(cd $$dir; make -V PKGNAME)
for every dir in _LIB_RUN_DEPENDS. But if instead we kept a file in /var/db/pkg called
something like +PACKAGE_NAMES, where as each port is
Ulrich Spoerlein wrote:
Stephen Montgomery-Smith wrote:
1. Pulling in the dependencies. This is in effect doing a make package-depends. You can
do this for yourself, and see that it takes a long time. I honestly don't see how to make
this faster, as presumably it involves calling make on
Stephen Montgomery-Smith wrote:
1. Pulling in the dependencies. This is in effect doing a make
package-depends. You can
do this for yourself, and see that it takes a long time. I honestly don't
see how to make
this faster, as presumably it involves calling make on all the dependency
Stephen Montgomery-Smith wrote:
And also, the only reason it goes slow is because it has to do
(cd $$dir; make -V PKGNAME)
for every dir in _LIB_RUN_DEPENDS. But if instead we kept a file in
/var/db/pkg called
something like +PACKAGE_NAMES, where as each port is created we add in a one
If you follow the thread, there's already some success in reducing the
time
required to register ports with many dependencies. On my system
registering
x11/xorg now takes between 2 to 3 minutes instead of 10, with all the
changes.
I consider that a remarkable improvement.
Absolutely a
Thomas Sparrevohn wrote:
If you follow the thread, there's already some success in reducing the
time
required to register ports with many dependencies. On my system
registering
x11/xorg now takes between 2 to 3 minutes instead of 10, with all the
changes.
I consider that a remarkable
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a very
significant way to solving the problem of registration taking so very long.
Stephen
You
Stephen Montgomery-Smith wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a
very
significant way to solving the problem of registration
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from
Mon, 14 May 2007 09:39:13 -0500):
Someone pointed out that what I was proposing in +DEPENDENCIES is
Probably me...
already to be found in +CONTENTS. So here is a proof of concept patch
to /usr/ports/Mk/bsd.port.mk (proof of concept
Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith [EMAIL PROTECTED] (from
Mon, 14 May 2007 09:39:13 -0500):
Someone pointed out that what I was proposing in +DEPENDENCIES is
Probably me...
Yes
already to be found in +CONTENTS. So here is a proof of concept patch
to
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how
On Sun, May 13, 2007 at 10:44:19AM +0200, [LoN]Kamikaze wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the
Kris Kennaway wrote:
On Sun, May 13, 2007 at 10:44:19AM +0200, [LoN]Kamikaze wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it
Hello Kris,
Saturday, May 12, 2007, 9:40:11 PM, you wrote:
KK I think that before you abandon something you should first understand
KK it.
Can you explain, why we need to register A depends on C / C required by A
in A - B - C chain?
I can not see any advantages, only disadvantages:
(1)
Lev Serebryakov wrote:
Hello Kris,
Saturday, May 12, 2007, 9:40:11 PM, you wrote:
KK I think that before you abandon something you should first understand
KK it.
Can you explain, why we need to register A depends on C / C required by A
in A - B - C chain?
I can not see any
Hello [LoN]Kamikaze,
Sunday, May 13, 2007, 3:53:29 PM, you wrote:
LK the decision has been made long ago
I want to understand: WHY has such decision been made?
--
Best regards,
Levmailto:[EMAIL PROTECTED]
___
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 00:02 -0500:
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns
Lev Serebryakov wrote:
Hello [LoN]Kamikaze,
Sunday, May 13, 2007, 3:53:29 PM, you wrote:
LK the decision has been made long ago
I want to understand: WHY has such decision been made?
Then I suppose you should take a look at CVS and have a look way back in time
when ports were first
Kris Kennaway wrote:
On Sun, May 13, 2007 at 10:44:19AM +0200, [LoN]Kamikaze wrote:
[LoN]Kamikaze wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it
On Sun, May 13, 2007 at 03:14:50PM +0400, Lev Serebryakov wrote:
Hello Kris,
Saturday, May 12, 2007, 9:40:11 PM, you wrote:
KK I think that before you abandon something you should first understand
KK it.
Can you explain, why we need to register A depends on C / C required by A
in A -
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name/+DEPENDENCIES file, which would be a kind of reverse of
package-name/+REQUIRED_BY. This
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 17:32 -0500:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name/+DEPENDENCIES file,
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 17:32 -0500:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 17:53 -0500:
Pav Lucistnik wrote:
Stephen Montgomery-Smith píše v ne 13. 05. 2007 v 17:32 -0500:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to
Stephen Montgomery-Smith wrote:
I have looked into making the registration and package-building process
even faster. It seems to me that the easiest way would be to redesign
the package database so that it also includes a
package-name/+DEPENDENCIES file, which would be a kind of reverse of
[LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register than to
download, build and install.
I think it's time to abandon the recursive pulling in of dependencies.
I think that you're missing the point of modular X; it was designed so
that things could be
Stephen Montgomery-Smith wrote:
Basically I think we are stuck on making make package-depends go any
faster.
However I do think that the modifications I made to pkg_create go a very
significant way to solving the problem of registration taking so very long.
Stephen
You are right about
With Xorg updated to 7.2 many ports take much longer to register than to
download, build and install. I think it's time to abandon the recursive pulling
in of dependencies.
___
freebsd-ports@freebsd.org mailing list
On Sat, 12 May 2007 12:32:38 +0200
[LoN]Kamikaze [EMAIL PROTECTED] wrote:
With Xorg updated to 7.2 many ports take much longer to register than
to download, build and install. I think it's time to abandon the
recursive pulling in of dependencies.
Does that matter all that much when there are
RW wrote:
On Sat, 12 May 2007 12:32:38 +0200
[LoN]Kamikaze [EMAIL PROTECTED] wrote:
With Xorg updated to 7.2 many ports take much longer to register than
to download, build and install. I think it's time to abandon the
recursive pulling in of dependencies.
Does that matter all that much
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register than to
download, build and install. I think it's time to abandon the recursive
pulling in of dependencies.
I think that before you abandon something you should
Kris Kennaway wrote:
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register than
to download, build and install. I think it's time to abandon the
recursive pulling in of dependencies.
I think that before you abandon
Le Sam 12 mai 07 à 19:40:11 +0200, Kris Kennaway [EMAIL PROTECTED]
écrivait :
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register than to
download, build and install. I think it's time to abandon the recursive
On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote:
Kris Kennaway wrote:
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register than
to download, build and install. I think it's time to abandon the
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote:
On Sat, 12 May 2007, Kris Kennaway wrote:
On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote:
Kris Kennaway wrote:
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote:
I've done a little poking around. As of right now, I think that the
registering takes a huge amount of time inside of a function called
sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c.
Has
On Sat, 12 May 2007, Kris Kennaway wrote:
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote:
I've done a little poking around. As of right now, I think that the
registering takes a huge amount of time inside of a function called
sortdeps which may be found in
On Sat, May 12, 2007 at 11:53:22AM -0700, Jeremy Chadwick wrote:
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote:
I've done a little poking around. As of right now, I think that the
registering takes a huge amount of time inside of a function called
sortdeps
On Sat, May 12, 2007 at 12:30:52PM -0700, Jeremy Chadwick wrote:
On Sat, May 12, 2007 at 01:53:36PM -0500, Stephen Montgomery-Smith wrote:
I believe that if this function is optimized, that practically all of the
slowness issues we have seen with pkg_add, pkg_deinstall, etc, will be
Stephen Montgomery-Smith wrote:
On Sat, 12 May 2007, Kris Kennaway wrote:
On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote:
Kris Kennaway wrote:
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
With Xorg updated to 7.2 many ports take much longer to register
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how to speed up the
make
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye.
72 matches
Mail list logo
