Request for Features: Ports Re-engineering
alepulver at FreeBSD.org
Mon Dec 17 08:00:07 PST 2007
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
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071217/bce2d30a/signature.pgp
More information about the freebsd-ports