mezz7 at cox.net
Thu Feb 15 21:20:55 UTC 2007
On Thu, 15 Feb 2007 12:17:00 -0600, <youshi10 at u.washington.edu> wrote:
> -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 own
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 beta
> 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 to
break stuff, I personal prefer Slackware or Ubuntu over Gentoo and portage
anytime for Linux.
> -Portage files are fetched via rsync.
What is speical about it if you put rsync as in Cons? Why replace it when
CVSup works fine?
I do realize that it's 2002.
> -Has separate portage files which are phased out over time, in case the
> portage maintainers move the files in one release. The maintainers then
> create an informative message which describes what's going on while
> emerging the package or going through the portage database. If possible
> the outdated package is pruned and the newer, more recent dependency is
I don't think I like this. Same comments for this in the first top.
> -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? :-)
> In light of previous statement:
> 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 screw
> 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 tools
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 hard
to get us to accept for our ports tree to change over to use new tools.
> 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 than
> welcome. That way we could ensure that the project gets done in a timely
> manner and can reduce bugs and think of better solutions (more people
> can help in thinking out of the box, the larger the group).
> PS Please reply on the @hackers list, if possible.
mezz7 at cox.net - mezz at FreeBSD.org
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org
http://wiki.freebsd.org/multimedia - multimedia at FreeBSD.org
More information about the freebsd-ports