Post a Comment
The DAG port* and pkg*-tools must walk for dependency and conflict checking has now grown by SEVERAL entries; watching portupgrade -N gnome2 listing the dependency "dots" is now almost comical.
Sadly, it also means that the "registering package install" phase is taking *ages*, because walking the /var/db/pkg directory to check for conflicts must naturally look into every x*, lib* and font* directory, and, with Xorg 7.2, those are pretty numerous.
There have been discussions about overhauling the installed ports and packages metadata backend, but most devs are frowning upon the idea of using SQLite (because of SQL) or relying entirely on BDB (because BDB breaks, period); actually, relying on single-file DBs is frowned upon because corruption that would otherwise only affect a single file on the /v/d/pkg tree will now blow the whole thing, and fully transactional DBs are too heavyweight for the purpose of storing this kind of information.
Well, files are not working very well either, at least not the way they're currently been parsed.
Some people proposed using a lightweight DB as a cache, and the /v/d/pkg filesystem tree as fallback to rebuild the DB in case of corruption. Despite obvious redundancy of information, and hence the necessity of keeping both sets of data in sync, that's the approach I liked the most.
Edit: newsflash! /me making grammar mistakes!
Edited 2007-05-19 19:29
It's amazing to me that people think that by just sticking everything in a binary blob that it'll just magically make everything blazing fast. The reason the port commiters don't want to use SQLite or BDB is because it has nothing to do with the problem.
The problem has nothing to do with the database format and has everything to do with inefficient algorithms for sorting large dependency graphs and the use of recursive calls to make.
Both of these problems have been addresses and are waiting to be commited to CVS. These should result in a 30 fold decrease in package registration time all without messing with the pkgdb structure.
http://www.freebsd.org/cgi/query-pr.cgi?pr=112630
http://www.freebsd.org/cgi/query-pr.cgi?pr=112765
>Sadly, it also means that the "registering package install" phase is taking *ages*, because walking the
Somewhat an exaggeration, maybe at a PIII800.
People don't sleep, there is already a solution in test to speedup it.
http://blogs.freebsdish.org/netchild/2007/05/17/speeding-up-the-pac...
Dude, I'm not that thick to report on something like that when I haven't experienced it myself.
Selected DMESG snips:
CPU: AMD Sempron(tm) Processor 3000+ (1680.01-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x40ff2 Stepping = 2
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR ,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
Features2=0x2001<SSE3,CX16>
AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!& gt;
AMD Features2=0x19<LAHF,ExtAPIC,CR8>
real memory = 535691264 (510 MB)
ad0: 58644MB <Maxtor 6Y060L0 YAR41VW0> at ata0-master UDMA133
Not top notch, but no slouch either.
ls /var/db/pkg/ | wc -l
583
Considering that
ls /var/db/pkg/ | egrep -i -e "^x" -e "^lib" -e "^font" | wc -l
284
is probably a fair approximation of what the xorg 7.2 metaport installs, and considering that I'm still not done installing Gnome 2, I wouldn't consider this to be an overcrowded system. Not by a *long* margin.
Registering any packages that have direct or indirect dependencies on xorg is taking in excess of 2 minutes here.
Anyway, MANY thanks to those who pasted those links to patches that greatly mitigate those speed problems. Beats the "ancient hardware" red herring anytime.
Edit: "considering" word was missing
Edited 2007-05-19 23:26 UTC
People don't sleep, there is already a solution in test to speedup it.
http://blogs.freebsdish.org/netchild/2007/05/17/speeding-up-the-pac...
Hm... Sorry. Just noticed you were among the people who posted links related to speeding up port*/pkg*.
Anyway, please, don't you ever use that "old P3-800" argument ever again, please, pretty please?
Please?
Edit: osnews v4 not handling quote closure correctly...
Edited 2007-05-19 23:59 UTC
Sadly, it also means that the "registering package install" phase is taking *ages*, because walking the /var/db/pkg directory to check for conflicts must naturally look into every x*, lib* and font* directory, and, with Xorg 7.2, those are pretty numerous.
There are PRs now to address the slow registering of ports. Threads on the ports mailing list show the reduction going from several minnutes to under 10 seconds.
Would have been nice if these were available before 7.2 hit the tree, but at least they are available. And they should hit the tree soon.
Ladies and gentlemen, please start your engines :o)
http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/041029.ht...
"As you may already know, the X11 team has been working hard for the past few months to upgrade X.org ports to 7.2. After a couple of weeks of testing, we've finally committed this upgrade. We also decided to make the PREFIX merge at the same time (moving X11BASE into LOCALBASE), which explains why there are thousands of ports affected by this commit."
"We also decided to make the PREFIX merge at the same time (moving X11BASE into LOCALBASE), which explains why there are thousands of ports affected by this commit."
This is what I've waited for. Now every program not belonging to the OS itself is installed in /usr/local, No more searching both /usr/local and /usr/X11R6.
The new Xorg will be interesting in upcoming FreeBSD based live file systems in order to autodetect GPU 'n stuff.
Congratulations, great work! Time to reinstall on some boxes. :-)
just upgrading ports and doing a make-install in /usr/ports/x11/xorg will not work
/usr/ports/graphics/dri is broken
the upgrade instructions
http://wiki.freebsd.org/ModularXorg
are well documented but look like a major headache for most mortals
i had planned on reinstalling for freebsd7, it looks like i'll just wait for this upgrade to make it in to a fresh release...whats the rush? its not like my monitor is going to start dancing when 7.2 is installed
anyone who knows if "make install" will ever do the trick, please comment
I don't know about Compiz but I guess it's almost the same as Beryl (except it's in one port). Beryl/Aquamarine hasn't been ported yet cause I don't use KDE and the new maintainer doesn't seem to be using it either.
Anyway, Aquamarine only serves one purpose AFAIK, handling KDE windows decoration themes, so you can perfectly run Beryl with Emerald (Beryl window decorator) and KDE.
Beryl and/or compiz will only work properly on nvidia cards. Xorg 7.2 on FreeBSD does not properly support AIGLX on either radeon or intel hardware. On intel cards, AIGLX will cause the machine to lockup when you stop X, and on radeon cards, AIGLX will cause the machine to lockup when starting X.
And, last I heard, even with nvidia cards you need to downgrade to an older version of the xrandr libraries than are available in the ports tree.
Adam
I'm just waiting on wpi (Intel 3945 a/b/g) to be merged, which will make FreeBSD a definite contender for my laptop
With that being said, is there any eta on FreeBSd 7.0 and have they added the required features which Nvidia listed on the mailing list? I haven't found a 'progress report' in that regard.
had to add a wm to /usr/local/lib/X11/xinit/xinitrc
(commenting out twm)
after adding /x11/xinit and some other stuff
my old 'starx ...' or whatever either retried X11R6's X(org) or ran twm otherwise, without running the following,
discovered by much trial and error (pkg_deleted -f /var/db/pkg/xorg (6.9 lots of, before installing xorg)
***********************************************************
#xinit /usr/local/lib/X11/xinit/xinitrc -- /usr/local/lib/Xorg
*********************************************************
^^^^ reason for this post, btw))
********************************************************
however I consider on this box the Xorg upgrade 'done' (I unfortunately for various reasons do not use portupgrade nor any other recc'd tool) and just the ports to bump. I expect to complete the UPDATING instructions smoothly, however taking several months (as I don't have a lot of time to do it all at once)
Edited 2007-05-21 00:47
Now if only adobe and flash would play nice i could wipe debian off this desktop heap and let it play nice with the rest of my systems. My 3 other systems, a file server a sandbox and an old mac g4, are constantly singing "one of these things is not like the other" with a huge grin. I wouldn't care if I wasn't doing web-dev part time.
I try to preview a group collaberation project with flash in it and BOOM seg fault. I got sick of kicking my wife of her mac so I could see what I was doing.
Sorry, off topic, I know. But it's so frustrating! And in no way Freebsd's fault. Sorry if it sounded like I was trolling, Im just mad at Adobe.






