Roger Marquis wrote: > Maintaining a port is so much easier than maintaining an RPM. I'm > talking night and day. With ports you don't have to generate a > distinct specfile
RPM specfile and dpkg/rules is the same and very simple for all decent upstream packages that behave well (that pass ./configure && make distcheck) > or build a separate binary package for every OS > version (multiplied by) every architecture autobuilders do, not you..., you only watch them FTBFS (wikipedia for more info) > All you need is the > makefile and a few patches. When a new release comes out most of > the time all you need change is the makefile's version numbers > (assuming patches still apply cleanly, and most of the time they > do). same applies for RPM and dpkg (and probably others), port's Makefile is nothing more/less than debian/rules > Another big advantage to BSD-style ports is that you don't have to > compile-in every dependency a package user is likely to use. These > can all be resolved, by command line or menu, at install-time. which also lowers the barrier to entry because I will probably not educate my grandma how to use make in order to get pidgin working > The result is 1) a significantly smaller number of installed > packages with the same functionality, 2) up to date versions of > all software and all dependencies, and 3) a far more stable and > secure environment. for those who care enough to go through all the hassle (see also Ubuntu: Applications: Add/Remove) > None of this need have any impact on the end-user experience. The > same management tools can work with either source or binary (for > proprietary software) packages. As far as front-end models, my > vote goes to aptitude/synaptic though yum/yumex is almost as good. > > Even with Sun's proven ability to provide support (SunSolve), and > superior kernel architecture (mach) There is 0.0% of mach in SunOS AFAIK HTH, Martin _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
