Call for feedback on a Ports-collection change

[Allan Bowhill]

Garance A Drosihn <drosih at rpi.edu> wrote:
:
:So, what I'm shooting for is a *doable* project, but one
:which leaves the ports-tree in a state where it would be
:easier to do some follow-up projects that would have much
:more obvious benefits than this step will have.

Raising the bar one notch at a time is sensible from a production
perspective, especially if you have a limited time frame and resources.

This change sounds like it does have immediate benefits for the user, if
the user interface doesn't change. It would probably have a positive
effect on the size of locate database and execution time for find, as
well as CVSup execution time.

I have no idea what, if anything would change in the packaging utilites,
sysinstall, package building scripts, CVS support utils, and
SGML/Web/Printed documents. There are also several third-party utilities
that interface with the ports tree directly that might be broken. Not
many.

It also might break some scripts at larger ISPs who build or track ports
with their own systems, but these groups are usually equipped to handle
changes. They might complain a bit, as big directory changes mean they
have to script for two different file and directory structures in their
repositories, based on date. This might also be a compelling reason to
make all the big changes at once, if it can be done.

Too many global changes to historically uniform directories and files
creates repository muddle, based on dates of change. Maybe this is not
all that important an issue to many *BSD users.

I can vaguely recall the last really big global change to ports, when
Satoshi (then Ports Manager) consolidated some files and directories to
reduce inode usage.

One thing I remember was CVSup having problems cleaning up old files and
directories. Perhaps I didn't have the delete option set, or the sup
datafiles got mangled, I can't recall. I can remember solving it by
deleting ports entirely, then re-CVSupping. At the ISP I worked, it
did cause automation problems, as we had built our toolset around the
older set of directories. We had to do some up-conversion of custom
ports we offered, and were forced to upgrade and re-evaluate new 
versions of ports that we offered as-is. Not the end of the world by
any stretch, but it cost programming hours to rectify.

What I'm saying is that the impact at tier-1 service providers is not
insignificant, especially those who offer jailed environments with
ports trees for their customers.

If you can afford to, I think it might be worthwhile to publish a short
document describing the anticipated design, benefits, and impact of your
idea. Then nobody can complain changes were dropped on them by surprise.

-- 
Allan Bowhill
abowhill at blarg.net

Chef, n.:
        Any cook who swears in French.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20040109/120031b9/attachment.bin