From owner-freebsd-questions Sun Oct 1 11:58:26 2000 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 6BE0037B502 for ; Sun, 1 Oct 2000 11:58:22 -0700 (PDT) Received: (qmail 35421 invoked by uid 100); 1 Oct 2000 18:58:16 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14807.35144.526882.224969@guru.mired.org> Date: Sun, 1 Oct 2000 13:58:16 -0500 (CDT) To: xavian anderson macpherson Cc: questions@freebsd.org Subject: Re: installing freebsd in an existing linux environment In-Reply-To: <106588189@toto.iv> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi xavian, First, welcome. Second, -questions is for questions (and, of course, answers). Whlie a diary of the conversion process could certainly be interesting, it's not really appropriate here. Restricting your mail to questions and pertinent information will get you better results. Why you're trying to do something may be pertinent, as someone may suggest an alternative approach that works better. You might make the diary-like items available on the web, and then post a announcement to -stable, or via daemon news. Finally, the one question I don't feel was dealt with adequately by Bob (no offense to bob): > i want the stability and security of the bsd kernel, matched with the > wide data base of linux packages, or as freebsd would refer to them, > ports. it seems that freebsd would simply overwrite existing files > with new ones is the old one has the same name. maybe the best that i > could hope for is that the old would have it's name changed or altered > to something like *.orig, *.old, etc. but then this may not be a > problem at all. i just want to know before i embark on this journey > into madness. First, a "package" is just what you think it is from Linux: a binary distribution of some application. A "port" is a collection of meta-information about a package. A makefile that will fetch the source, some patches to the source, a list of files, md5 checksums, and suchlike things. Packages are built from ports with "make package" in the port directory. Second, the FreeBSD ports are a pretty wide data base themselves. I keep things installed from ports separate from things I installed myself. The ones I installed myself come to about 3% of the total. About half of those are available via ports, but I chose to install by hand for some reason (say to tweak source, or track the development version more closely than ports does). The answer to your question is that there is no mechanism for preventing collisions. On the other hand, the ports collection is maintained by one group. If you create a port and one to make it public, you submit it to them, and they add it to the collection. A port can create a binary distribution, but the only people I've seen distributing those are the FreeBSD and ApplixWare (who provide a package of their commercial product for FreeBSD). The ports crew is pretty good about recognizing applications that provide a private copy of some library that's available as a stand-alone, and making the library a separate port that the main one depends on. With that in mind, the only time you run into file conflicts in ports is with what are really different versions of the same port. For instance, a number of things in the print collection come in "-a4" versions as well as the US letter version; there are also some ports with -devel (developer) versions as well as stable versions. The real kicker is libraries that are available in multiple versions - and the different versions are used by different ports. If you track ports properly (i.e. - you keep the entire ports tree up to date), most of these problems will be dealt with by upgrading the dependent ports when a library changes. However, some applications won't work with older versions of a library, which creates a problem. It's rare enough that I haven't run into it, so I can't tell you how - or if - it's solved.