Date: Thu, 15 Feb 2007 15:22:35 -0600 From: "Jeremy Messenger" <mezz7@cox.net> To: youshi10@u.washington.edu Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: portupgrade O(n^m)? Message-ID: <op.tns6zxer9aq2h7@mezz.mezzweb.com> In-Reply-To: <Pine.LNX.4.43.0702151017001.16360@hymn07.u.washington.edu> References: <Pine.LNX.4.43.0702151017001.16360@hymn07.u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Feb 2007 12:17:00 -0600, <youshi10@u.washington.edu> wrote: <snip> > =3D=3D=3D=3D=3D > Pros: > =3D=3D=3D=3D=3D > -It's written in python (portable). Isn't our more portable for hardware than Python? Also, it is smaller? > -It's a system which focuses on ports compilation from source, not = > binary package installation. This is very cons. The ports can do both, so it is more flexible and is = = pros than this. In our ports tree, you can even choice to create your ow= n = packages, install your own packages that was built by you, use FreeBSD = packages or compile by via ports tree. > -Stores information in a db format (not Berkeley DB, but something = > different)for entire system in a common file; stores installed leaf = > package information in another simple textfile. > -Has flags for stability reasons, since some packages are alpha or bet= a = > and don't compile under certain architectures. No thanks, I am against this. I have seen the messy over at Gentoo's = forums for you can't do the mix very well. Our ports have the better = stability than their for in both stable and bleeding edge at the same = time. I have used Gentoo before very long time ago and it is too often t= o = break stuff, I personal prefer Slackware or Ubuntu over Gentoo and porta= ge = anytime for Linux. > -Portage files are fetched via rsync. What is speical about it if you put rsync as in Cons? Why replace it whe= n = CVSup works fine? http://www.gentoo.org/news/en/gwn/20021223-newsletter.xml#doc_chap2_sect= 4 I do realize that it's 2002. > -Has separate portage files which are phased out over time, in case th= e = > portage maintainers move the files in one release. The maintainers the= n = > create an informative message which describes what's going on while = > emerging the package or going through the portage database. If possibl= e = > the outdated package is pruned and the newer, more recent dependency i= s = > merged. I don't think I like this. Same comments for this in the first top. > =3D=3D=3D=3D=3D > Cons: > =3D=3D=3D=3D=3D > -It's written in python (not fast). And it is not in base system. It requires Python to be install in the = different way when our package system is based on Python. And Python = breaks script more often than what we have in base system. > -Uses rsync. Why put rsync in Pros too? :-) > =3D=3D=3D=3D=3D=3D > Point: > =3D=3D=3D=3D=3D=3D <snip> > =3D=3D=3D=3D=3D=3D=3D > In light of previous statement: > =3D=3D=3D=3D=3D=3D=3D > > I wasn't trying to port the pkg_* and port* utils to C++ thinking that= I = > would magically get more optimized code. Sure, C++ is much better than= = > ruby at optimizations if done correctly, but C++ is also easier to scr= ew = > up than ruby or perl or python, because you have the power to shoot = > yourself in the foot easier (not as much as C or ASM, but close). > > The point was that with C++ we could finally get a set of standardized= = > tools and a common interface for FreeBSD for managing ports / packages= = > which could be included in the base system, not a bunch of little = > specialized tools and packages. If you can make C or C++ or whatever what we have in the base system too= ls = better (is a must) than what we have now in ports tree, then I have no = problem with it. Go ahead write it, but do expect for that it will be ha= rd = to get us to accept for our ports tree to change over to use new tools. Cheers, Mezz > I'll have to approach this problem from a black box perspective and be= = > carefully in planning this out, but my goal is to be as backwards = > compatible friendly as possible or at least provide migration tools to= = > ease the move from the old system to the new one. > > Again, if anyone is interested in helping me out, it would be more tha= n = > welcome. That way we could ensure that the project gets done in a time= ly = > manner and can reduce bugs and think of better solutions (more people = = > can help in thinking out of the box, the larger the group). > > Thanks, > -Garrett > > PS Please reply on the @hackers list, if possible. -- = mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.tns6zxer9aq2h7>