What I really like is the way FreeBSD has laid out there port making system.
I liked it so much, I downloaded the FreeBSD port making tree into linux and tried a "make install." It didn't work of course. But anybody got and idea about how much work it would take to get whole ports structure paralleled for Debian or Redhat? All the code is open, I believe. Edward Ing
Re: What I really like is the way FreeBSD has laid out there port making system.
You would have to examine every source patch to determine if it was really required and if debian patches are required. I use the freebsd ports quite a bit on a bsd machine and I don't really care for a debian version of the same beast. > > I liked it so much, I downloaded the FreeBSD port making tree into linux and > tried a "make install." > >
Re: What I really like is the way FreeBSD has laid out there port making system.
On Tue, Nov 24, 1998 at 11:55:24PM -0500, Edward Ing wrote: > I liked it so much, I downloaded the FreeBSD port making tree into linux and > tried a "make install." > > It didn't work of course. But anybody got and idea about how much work it > would take to get whole ports structure paralleled for Debian or Redhat? All > the code is open, I believe. There's not really much need, as I see it. A FreeBSD port consists off some control info and a patch; the makefile grabs the source off the net, applies the patch, and compiles and installs the software. Debian source packages also consist of the upstream source and a patch. However, we provide precompiled binaries for all the packages where FreeBSD do not. Because we provide binary packages, you can remove the software with "dpkg -r "; there's no easy way to remove something installed through a port on FreeBSD, because there's no packaging information. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: What I really like is the way FreeBSD has laid out there port making system.
Hamish Moffatt ([EMAIL PROTECTED]) wrote... (Hey, I know you :)) > On Tue, Nov 24, 1998 at 11:55:24PM -0500, Edward Ing wrote: >> It didn't work of course. But anybody got and idea about how much >> work it would take to get whole ports structure paralleled for >> Debian or Redhat? All the code is open, I believe. > There's not really much need, as I see it. A FreeBSD port consists > off some control info and a patch; the makefile grabs the source > off the net, applies the patch, and compiles and installs the software. > Debian source packages also consist of the upstream source and a patch. > However, we provide precompiled binaries for all the packages where > FreeBSD do not. It would be -very- nice if you provided sorta "patch"es though - since we have binaries I guess a "patch" would consist of all the files in a particular .deb that have changed since the last release. I suspect this would be a fair bit less that all the files in a lot of casess. You could get apt/dselect to do this automatically if it found both a "patch" and the previous installed ver. bekj -- : --Hacker-Neophile-Eclectic-Geek-Grrl-Gay-Disabled-Boychick-- : [EMAIL PROTECTED] http://www.tertius.net.au/~gossamer/ : All you have to do to work on ZigZag is fully unscrew your head : and put it down in a safe place where it can be sure to watch : you. -- Ted Nelson
Re: What I really like is the way FreeBSD has laid out there port making system.
>> "G" == Gossamer <[EMAIL PROTECTED]> writes: G> It would be -very- nice if you provided sorta "patch"es though - G> since we have binaries I guess a "patch" would consist of all the G> files in a particular .deb that have changed since the last G> release. I suspect this would be a fair bit less that all the G> files in a lot of casess. Binary diffs of packages are currently discussed on debian-devel. Check the mailinglist-archive for the postings. Ciao, Martin
Re: What I really like is the way FreeBSD has laid out there port making system.
*- Gossamer wrote about "Re: What I really like is the way FreeBSD has laid out there port making system." > Hamish Moffatt ([EMAIL PROTECTED]) wrote... > > (Hey, I know you :)) > >> On Tue, Nov 24, 1998 at 11:55:24PM -0500, Edward Ing wrote: >>> It didn't work of course. But anybody got and idea about how much >>> work it would take to get whole ports structure paralleled for >>> Debian or Redhat? All the code is open, I believe. >> There's not really much need, as I see it. A FreeBSD port consists >> off some control info and a patch; the makefile grabs the source >> off the net, applies the patch, and compiles and installs the software. >> Debian source packages also consist of the upstream source and a patch. >> However, we provide precompiled binaries for all the packages where >> FreeBSD do not. > > It would be -very- nice if you provided sorta "patch"es though - since > we have binaries I guess a "patch" would consist of all the files > in a particular .deb that have changed since the last release. I > suspect this would be a fair bit less that all the files in a lot of > casess. > > You could get apt/dselect to do this automatically if it found both a > "patch" and the previous installed ver. > > > bekj > There was a discussion of this just this month on debian-devel. Look at the archives, http://www.debian.org/Lists-Archives/debian-devel-9811/threads.html, for the subject 'debian binary diff system ?!'. Someone has worked on a script but I think it is not going to happen overnight. -- Brian - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." - unknown Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -
Re: What I really like is the way FreeBSD has laid out there port making system.
On 25-Nov-1998, Gossamer <[EMAIL PROTECTED]> wrote: > Hamish Moffatt ([EMAIL PROTECTED]) wrote... > > (Hey, I know you :)) Hey, I know both of you! > > > On Tue, Nov 24, 1998 at 11:55:24PM -0500, Edward Ing wrote: > >> It didn't work of course. But anybody got and idea about how much > >> work it would take to get whole ports structure paralleled for > >> Debian or Redhat? All the code is open, I believe. > > There's not really much need, as I see it. A FreeBSD port consists > > off some control info and a patch; the makefile grabs the source > > off the net, applies the patch, and compiles and installs the software. > > Debian source packages also consist of the upstream source and a patch. > > However, we provide precompiled binaries for all the packages where > > FreeBSD do not. > > It would be -very- nice if you provided sorta "patch"es though - since > we have binaries I guess a "patch" would consist of all the files > in a particular .deb that have changed since the last release. I > suspect this would be a fair bit less that all the files in a lot of > casess. xdelta can create binary patches and it does a better job than just keeping changed files -- it will describe partial changes to a file too. This would be really nice for packages that only change a little bit with each revision but are very large. The problem with this approach is mostly configuration (e.g. setting up the scripts to create such patches, and further scripts to download and apply them). The way to do it is (at the ftp site end): - Provide patches from each revision to the next revision. - Maintain the invariant that the sum of the size of all the patches is less than the size of the latest revision of the package (there's no point downloading 5 patches to go from 1.0-1 to 1.0-5 is it is cheaper to just download 1.0-5 outright. If there is no point downloading them, there's no point providing them for download). So when you create a new patch, delete the oldest patches until this invariant holds. - You can just transfer patches from mirror to mirror, and the mirror can use the patch to upgrade the package from one version to the next. Then the client (dselect/apt) end just has to download the patches necessary to go from current rev to latest rev, or if the patches are not available, just download the package. This is assuming the client has the previous version somewhere nearby, and it *knows* that the previous version is *nearby* (e.g. cheap/quick to transfer) while the patch is slow/expensive. Note that what the clients do and what mirrors do is really pretty similar, it's just the client does it on demand, one package at a time, while the mirror does it for all packages. The problem is that on average this will double the size of the ftp archive. But it will reduce traffic. Except people will probably just upgrade more often (the same way that building freeways increases traffic). -- Because I dislike being quoted I lie almost constantly when talking about my work. -- Terry Gilliam Tyson Dowd <[EMAIL PROTECTED]> http://tyse.net/
