On Sun, Feb 14, 2010 at 4:37 PM, Xiaofan Chen <xiaof...@gmail.com> wrote: > Yeah I think openocd-devel port is the way to go. I do not really > like the port system very much due to the fact that many > mirrors are dead. The binaries are also not often updated. > Many ports are actually quite outdated.
Almost all port has its own binary representative that can be installed with "pkg_add -r" ot better "portinstall -P" or "portinstall -PP" utility (-P tries to fetch binary and build the binary otherwise, -PP will only work on binaries and fail if none if found). If no binary is found, you can always built the program from sources with use of Port system - and all the patching and os-specific quirks are done for you by port maintaner. In fact mirrors are not port-system related but package-related - if package has some mirrors outdated port can provide alternative list of sources for download. Port tree is centralized and hosted by a FreeBSD project and it works fine if you can fetch it - if a package has outdated mirrors, this is a package fault. The other situation is when port is outdated itself - then maintainer can be informed and asked for an update, or anyone update the port with maintaner permission. For the moment when new binaries propagate after a port sources, user can build the package himself or wait for the binary - like in case of libftdi, it will take few days. If there is no port available for a program, anyone can create it and add to the port tree. I know this may look complicated, especially for Windows or even Linux user, but this is very clear and logical structure. I call this "raw". Nothing is done for the user unless the user use tools that automates some tasks (ie. portinstall, portupgrade). This way the whole system is consistent, and it really makes life easy especially in a long term use :-) In a simple words - if you want the binary of the OpenOCD you can download it from a remote server, when you want to make your own specific demands like interface change, you can build the port yourself. But you dont have to patch the source files, edit them, or do whatever its needed to build - you just simply go into a port directory and type make config/install/deinstall/clean. Prepating the automation is done by a maintainer, only once - when creating a port (program) release, so noone is forced to patch or search for dependencies himself later. But nothing more can be archeived than is specified by a maintainer within in a port Makefile, or the maintainer must be requested for an update... this way there is only one package in the system, and it works always the same predictable way for all users in the system. > For that ARCH Linux seems to be much better since it > provides updated binaries and at the same time provides > the source packages. Please remember that Gentoo portage and the Arch linux are both somehow based on a FreeBSD philosophy - my friends use Arch Linux and once I helped him even to edit /etc/rc.conf :-) Also for about half a year I have noticed minimum two situations where upgrading Arch system made it inconsistent or non-working state (and a lot of uresolved dependencies or conflicts in distros like Fedora)... this did not happen for me on FreeBSD :-) > > Well, in FreeBSD you don't build the packages yourself from scratch - > > this is the reason that Ports exists - to be able to build the package > > from source with some options enabled/disabled, but the OS specific > > quirks are done by the maintainer. > > I think this is plainly wrong. If FreeBSD needs some quirks, the > patches should be submitted to the upstream and integrated > into the main tree. Now you see - this is the main difference between Linux and the BSD - Linux is the operating system with its kernel and the upstream is the kernel source where anyone can add the patches and do some quirks - this often ends in changing the API and the API, so even the A.B.C.n kernel can be incompatibile for different "n", and this makes this system unreliable and its maintenance very hard to accomplish. With FreeBSD or way different - there is a kernel and the base which is somehow standarized - user can create whatever he/she likes in the "/usr/local" area, also port tree resides in /usr/ports as a part of the system, but the system can work without "/usr/local" and the "/usr/ports", or even "/usr". What is more - a totally different system can run the same "/usr" that would be a difficult task for different Linux distribution. There are no problems in BSD like "/etc/init.d" versus "/etc/rc.d" or even "/etc/rc.d.blahblah", there is no problem with the parse of the config files or misleading device names (ie. linux eth0+eth1 vs bsd nfe0+rl0). Because the "main tree" here is a Port System, and it is separated from a system core, there is no "intergrating into a main tree" that could make system inconsistent, and I like this organization :-) Best regards! :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
