Request for Features: Ports Re-engineering

[Alejandro Pulver]

On Mon, 17 Dec 2007 06:44:25 -0800
Brian <bri at brianwhalen.net> wrote:

> Aryeh M. Friedman wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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
> >
[...]
> I dont use X on FreeBSD, so cannot comment on al th Xorg stuff.  Keeping 
> in mind that I believe it is appropriate for this new tool to make it at 
> lest a little easier on new users, while still giving them valuable 
> info, I suggest the following.
> 
> 1. I would like for the new equivalent of portupgrade -P to actually 
> find and install packages more often than building ports, currently this 
> is not the case, for me at least.

IIRC this issue isn't related to portupgrade but to the package builds,
which aren't always up-to-date with ports. And this has to do with
available resources to build them. Of course if the ports system
performance is optimized they will build faster. But in general I think
improvements could be made, like (if not already done, AFAIK tinderbox
has an option to run parallel builds, but don't know about pointyhat)
using multiple processors. And maybe even a new build system that
doesn't completely recreate the clean environment every time.

> 2. If the tool implemented the functionality of fastest_cvsup when 
> downloading files from FreeBSD servers, users would likely see a 
> performance improvement, and FreeBSD would likely see better load 
> distribution.

Ordering preference of MASTER_SITES would be a good feature, combined
with speed calculation. Currently there is only RANDOMIZE_MASTER_SITES.

The new system will be modular from the beginning so adding more and
more things shouldn't result in performance overhead (as it happens
now).

> 3. System changes that are necessary for proper functionality are 
> delivered via email to a specified email address or to some easy to find 
> and refer to file, with the option to have them done by the install 
> routine if the user desires that.

This is currently up to the maintainer, and some framework should be
provided by the system.

> 4. Log of what ports were installed/upgraded/downgraded at what time.
> 

portupgrade already has logging facilities (I guess you already know),
but integrating them in the system would offer some advantages:

1. Ability to avoid showing build output, keeping it in the log.
2. Keeping track of port operations internally (which could be useful
   for processing files like UPDATING/MOVED later, and security checks).
3. Accurate automated bug-report generation.

Best Regards,
Ale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071217/bce2d30a/signature.pgp