Limitations of Ports System

[Aryeh M. Friedman]

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

Matt Dawson wrote:
> On Friday 14 Dec 2007, freebsd-ports-request at freebsd.org wrote:
>> I was not planning to skimp on the requirements at all but the test
>> case is xorg.
>
> A far better test case, IMHO, would be to run a similar build to the
pointyhat
> cluster if you're serious about *replacing* the ports system. Unless a new
> system can do this, as well as being able to produce packages for a
> centralised port build system for multiple machines (yes, you can do this
> with NFS and a little thought), the metaphor "snowball in hell" springs to
> mind.

In the parlance of testing I consider xorg to be a large but basically
a unit test.  It has the following advantages:

1. Just enough external depends to not make it completely trivial
(thus ideal for a unit style test)

2. Certain ports with in the system behave different depending on the
order stuff is built in thus this serves as a good proof that DAG
scanning is working on a non-trivial DAG

3. Unlike attempting to build the entire ports collection it is a
relatively stable target (again an other key requirement for a unit test)

Once xorg works correctly I will consider the new system to be alpha
for the purposes of scaling it up to a static build of the whole ports
system (alpha2) and finally the beta is doing it against a non-static
ports system (i.e. having the two systems track each other).   So when
I said release I did not mean entery into production I just meant
complete enough to allow non-core developer use.   The idea is except
for handling special cases as gracefully as possible the system is
complete after xorg and special cases is where it becomes larger then
what a small team of 1 or 2 people can handle.   This does not
preclude refactoring on behalf of the core team to make it so there as
few special cases as possible.

>
> The job you've given yourself is an elephant. I'll leave it up to
others to
> decide if it's white or just too large to eat on your own all at once.
> Furthermore, if said elephant isn't consumed in its entirety, expect some
> resistance to your proof of concept code from some unexpected sources
since
> the ports system isn't just the package management system some people
seem to
> think it is.

Proof of concept is a little stronger then how I would describe it.
>
> Looking at all this from a user's perspective is fine and dandy until
you have
> a release to do. The ports are tied into bits of the base system in
various
> ways, for example, make release or USE_OPENSSL=base. The current system,
> although appearing to drip with legacy methods and what look like arcane
> rituals to appease the make god (until you understand how it all fits
> together), is very powerful - perhaps more so than any other package
> managment system I've ever used - and is structured to work for end users,
> the release engineering and ports management teams. I suspect this is
why so
> many @FreeBSD.org replies were negative.

The general model I have in mind more then enough accounts for this
interplay... but this entire discussion is getting ahead of the
project we still don't have a clear idea of the project scope.
>
> I don't wish to rock the boat and start another 8 kids 1 toy discourse and
> there is certainly no malice or insult intended, but the ports system
is so
> much more than getting X installed on a desktop box. First and foremost,
> release engineering depends on it. Change can be good, but always remember
> the alternate definition of progress: Taking the best of what you have.
And
> ruining it.

I understand this completely (one reason I am doing this is I am
working on a commerical OS that will need near equivelent
functionality and this is the perfect way to prototype the concepts
without creating a all or nothing risk [i.e. FreeBSD can always fall
back on the current system where is the OS I am working for all
intensive purposes will be stuck with what ever solution is
implemented on it]).   X is really nothing more then a large scale
unit test.

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

iD8DBQFHYmbMzIOMjAek4JIRAtiwAJ9EsK2iBDmwqlr2DoZrJzedqwjeXACgpiGk
LVPJXVFIZgwYWd0XBt7s0zo=
=uqaP
-----END PGP SIGNATURE-----