scope of the port re-engineering project

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Montgomery-Smith wrote:
> Aryeh M. Friedman wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Disclaimer:
>>
>> This does not commit me, anyone else and/or FreeBSD to an course
>> of action nor does it imply such a commitment.
>>
>> Assuming that the following is true:
>>
>> 1. There is a "proven" need to re-engineer the ports system as
>> demostrated by posts to -ports@ and the results of the survey on
>> re-engineering the ports system
>>
>> 2. Any system will correct your own personal "worst aspect" of
>> the ports system but will not do so at the expense of breaking
>> any high level functionality
>>
>> Please answer the following questions:
>>
>> 1. Using the items listed in the next section please select the
>> best scope of the project assuming that 100% backwards
>> compatibility with the current ports system is maintained?
>>
>> 2. Using the items listed in the next section please select the
>> best scope of the project assuming that 100% backwards
>> compatibility with the current ports system is *NOT* maintained?
>>
>> Possible project scopes:
>>
>> a. Refactor the current system only b. Redesign and recoding of
>> the current system c. Attempt to unify all methods of FreeBSD
>> software installation into a single system d. Same as c but for
>> all BSD like OS's
>
> 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 I had lots of time on my hands, I think I would redo ports
> _without_ using "make" as its primary scripting tool.  Mind you,
> I'm not sure what I would use in its place - perhaps its own
> scripting tool written from scratch? The difficulty with using
> "make" is that it isn't linear.  For example (and this was my
> bugbear), to figure out "make -V PKGNAME" the program has to read
> and process every single line of the makefile, including all of its
> ".includes".  And while perhaps this issue is a bit frivolous,
> nevertheless I bet that this is one of the reasons why people
> creating ports make mistakes setting up the dependencies.

Cook, scons, ant and several other modern dependency tools offer a
good framework for per package methods for handling this (see
Miller97) but as far I can tell there is no good tool that solves this
at the inter-project level and thus the final result would be likely
modeled on one of the above DMT's but would be home grown.

>
> Finally, I really do like the difference between ports and
> packages. Please keep both of the "build from source" and "install
> binaries" capabilities.

Even though we are not in the requirements phase this is one of the
requirements I think is a must I would even go a step further and say
the two should be completely interchangeable (which they aren't right
now... i.e. you use one or the other exclusivally for all packages)
>
>
> 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)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYD7NzIOMjAek4JIRAvzsAKCKubnQxw7EbVHJ1LdCS+Cadq24EQCfe6gx
z1JZPbCahjsmhn/+bsaIRJQ=
=Fo8B
-----END PGP SIGNATURE-----