Request for Features: Ports Re-engineering

Aryeh M. Friedman aryeh.friedman at
Mon Dec 17 17:44:10 PST 2007

Hash: SHA1

Stephen Montgomery-Smith wrote:
> Aryeh M. Friedman wrote:
>> Hash: SHA1
>> In order to finalize the general nature of the ports re-engineering
>> effort this thread is designed to specifically explore the features
>> people want to see.
>> Please supply one or more of the following:
>> * Up to 4 user stories of how you would like to use the ports system
>> (may or may not be possible in the current one)
>> * Up to 4 use cases for how you would like to interact with the ports
>> system
>> * Up to 4 features/requirements you think the new system should have
>> * Up to 4 features/requirements that you feel *MUST* remain from the
>> current system
>> * Any non-functional requirements you can think of
> One thing to look at is package building.  I don't know how they
> build the official packages, but my guess is that they build each
> one from a clean system.  But, for example, you have tons of little
> ports each depending on xorg-server, and to rebuild xorg-server for
> each little port must be a real burden.
This is defently something to look at down the road but it would
require the ports system to be more OO then even ports 2.0 envisions
(at least in it's first release)
> On the other hand some ports really need to be built from a clean
> system.  Some of them autodetect ports that are already installed,
> and then change options appropriately.  (Maybe some of the
> multimedia ports like vlc do this.)  My guess is that this is to
> some extent unavoidable because the "configure" script in the port
> build process probably does this as well.  Anyway, perhaps this
> autodetecting of ports to provide options needs to be built into the
> system in a systematic manner.  Then robotic package builders could
> be trained to glean this information from the build tree (what you
> refer to as the DAG - is that "directed something graph"?).

Directed Acyclical Graph.   I would like to move towards depractating
the concept of the ports system being a tree since this leads to some
rather bad methaphorical thinking about it.   For example it leads to
the belief that the entire system can be treated as a state machine
(i.e. it need not scan the entire input run before it starts) whereis
treating it like a DAG is more the lines of treating it as say set of
relationships between ports that needs to be managed as a whole
because of the cascading nature of changing a config.   The initial
release will not add enough OO'ness at the build level (but it will be
ready for it) to intergrate ports/packages.
> I also use packages for my private system.  I have one fast computer
> where I build all my ports, and then make packages from them to
> distribute to the other computers.  But I use "pkg_create."  The
> disadvantage of this is that you don't get all the candy (e.g. the
> messages in pkg-message, etc).
> I used to build my ports, then do a massive "make package" on all
> the built ports.  But "make package" is designed so that it only
> works properly if done before any other port is installed.  This is
> because you might add autodependencies to the package which were not
> part of the original build.  "make package" could actually get this
> dependency information from /var/db/pkg, but it doesn't.  (I filed a
> PR to effect this change, but no-one else felt it was important.  In
> particular, space is a premium on because the more you
> add to it, the longer things like "make index" take.)

The first release of the system will not be apple to deal with this
any better because it will require much more OO like building proceses.

- --
Aryeh M. Friedman
FloSoft Systems
Developer, not business, friendly
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-ports mailing list