• AndrewPantyukhin
• Ports
• iport

Codename iport

iport is codename for a collection of scripts that helps me with port-related tasks. It is in early stage of development. This page outlines some of design decisions, short- and long-term goals.

Language of choice is Bourne shell at this time. Perl and C may be considered later.

Data storage

Can we justify using a database for managing ports? Portupgrade has some annoying db-related tasks, portmaster could do better if it did have some db. The problem is the way we update ports makes an effecient db solution difficult. In the future, we'll probably develop some server-side solution, like an INDEX file, but in a more efficient format and schema.

At this moment iport tries to avoid using any type of SQL database, and even abstains itself from relying on the INDEX file. iport will try to achieve desirable performance through maintenance of multiple strictly formatted log-like files and replaying them when it needs to.

Some random ideas

• make -V PORTVERSION is expensive. We can first grep for it

  • If a Makefile only contains one line with "PORTVERSION" and it matches something like ^PORTVERSION=[space]*[0-9.]*$ and it only includes bsd.port.mk, then we can tell what the version is for sure without make

• We can use CVS id strings to detect a change in a makefile, but it's always better to have portsnap/cvsup/cvs output.
• We should try to avoid pkg_* as much as we can. At least if we can find a more efficient solution.
• Track includes, backwards and forwards
  • Be able to tell what ports might have changed whenever any file is changed
    • It might be bsd.port.mk
    • It might be some Makefile.common
    • It might be some distinfo in some master ports
  • Make intelligent decisions
    • If bsd.foo.mk does not contain PORTVERSION.*=, then ports that include it won't have their versions changed if bsd.foo.mk changes
      • There might be a catch in the example, like AAA=PORTVERSION ${AAA}=1.2.3
      • Decisions must be based on both the old and the new versions of bsd.foo.mk
• Keep parseable log files with timestamps
  • Log when portsnap changes something
  • Log when cvs/csup/cvsup changes something
  • Log when we do something about a change, e.g.
    • Fetch a distfile of an updated port
    • Update info about an updated port in some kind of INDEX/cache/db
    • Upgrade the port (what jail?..)
  • Log when something fails
  • Log when we analyze a failure
  • Log when we resolve a failure
  • Never remove entries from logfiles - there should be a separate routine to do that from time to time to save space and keep parsing fast

  • Decide if an entry is still relevant by comparing timestamps to each other and to date

• Keep per-session output dump files
• Save output in dump files, but make it possible to display on screen

• Consider using shcurses if we're crazy enough about Bourne Shell.

Options:

• Here's what I think about OPTIONS. The idea is good, but the implementation involves imperative per-port interaction, which is dreadful. OPTIONS management should be centralized from a user's point of view. Portmaster gives a chance

• Don't ever respect OPTIONS