scope of the port re-engineering project

Aryeh M. Friedman aryeh.friedman at
Wed Dec 12 12:58:30 PST 2007

Hash: SHA1

Stephen Montgomery-Smith wrote:
> On Wed, 12 Dec 2007, Aryeh M. Friedman wrote:
>> Hash: SHA1
>> Stephen Montgomery-Smith wrote:
>>> Aryeh M. Friedman wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> I'm not sure what the words "refactor" and "recode" mean here.
>> Refacoring is to use the existing framework and make tweaks to it.
>> Recoding is to start with a fresh piece of paper and see what emerges.
>>> ...........
>>> If you really do all the heavy lifting, it is something I will
>>> admire. Not least because you might do all this work and find
>>> people are too conservative to use it.
>> I have my own personal reasons for wanting to do most of the work my
>> self (prototype for a commerical package I am looking at developing...
>> note there will be no functional diff between the two systems just the
>> addition of some smoothing of rough UI edges in the commerical one)

Forgot to mention the target platform for the commercial tool is not
any variant of Unix (though it could be ported trivially)
> If I were going to do this (and I most certainly am not!) I would
> opt for the recoding from scratch, but doing so in a very backwards
> compatible fashion.  I would create a framework in which ports could
> be created with configuration files similar to, but more
> straightforward, to the current "Makefile"s.

The only requirement I consider to be in stone right now is "100%
backwards compatibility"
> Then I would work hard on creating a script that automatically
> converts the existing ports into the new ports system.

That will have to be worked out in detail but obviously some
conversion tool is needed.
> This means that people should be free to switch to your system
> whenever they like.  Most people will keep using the existing system
> because of fear (and reasonable fear) that your new system will have
> a lot of bugs (that any new project will have) and that it might
> even ultimately fail. Then if your system really is noticeably
> superior, people will begin switching to yours and eventually the
> existing structure will fall to the wayside.

I never expected a wholesale switch over even though the details are
not clear yet I expect the two to live side by side several years at
> One more thing.  I personally am very impressed with the existing
> structure of "var/db/pkg."  If you can preserve that as well, then
> people will be able to switch back and forth willy nilly, and they
> will be even more willing to try out your system.

That is part of backwards compatibility.
> Finally, don't get depressed when (or if) you roll out your new
> system, that it has a lot of problems and/or detractors.  Remember,
> for example, those early ugly days when Netscape had just been made
> open-source, and it looked likely to bite the dust.  And now it is
> threatening IE!  And even if your new system doesn't get adopted,
> when FreeBSD does eventually get a complete rehaul of the ports,
> many of your ideas will be there.

Part of the reason for the drawn out process vs. me just getting in
there and hacking code is attempting to make those mistakes as cost
efficient as possible.
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-ports mailing list