oscartheduckin’ around

October 12, 2008

decisions, decisions, decisions

Filed under: freebsd, ruby — Tags: , , , — oscartheduck @ 8:04 pm

I’ve been thinking about writing a new ports installation tool which solves a few problems I’ve always thought would be neat to solve. Thus:

1. decision 1 — write a new ports tool or extend an existing one?

This is really hard. I’d write a new ports tool in ruby or shell. Guess what the two existing main ports tools are written in? That’s right, ruby and shell! So I just sit here thinking about the wisdom of potentially rewriting a lot of functionality. Especially with portupgrade being written by a hacker who’s ten times the programmer I am, and portmaster being, well, fucking fantastic.

Here’s some of my aims:

1. The ability to instruct a remote machine to build every port needed
for a local upgrade of ports as a packaged to be pkg_added.
2. The ability to cross compile everything. This means that a local
arm board can upgrade its onboard dns server by having a remote
xeon based computer build the port.
3. The ability to run the command without super user privileges. I
want to have a directory I have write access to that my ports
can build to and be able to do an upgrade of those ports
4. The ability to synchronise ports across machines. This should be
architecture independent, and should take into account that
ports can with this tool be installed into home.

Which leads to decision 2:

2. How do I technologically best accomplish this?

Which is the same as decision one, really.

There are so many decisions. How do you search for a port when someone wants to install it? The other two tools I usually use for this stuff answer this question by saying “we don’t”.

So, accepting my premise that I’m not as good as these other folks at solving this issue, I won’t either.

A second: how do you determine if a port is to be upgraded? Well, there are two options I see:
1. roll my own method of doing so
2. use someone else’s method of doing so

I prefer the idea of number 2. Software is something that should be built modularly, so that each piece can be upgraded independently. And if I just use someone else’s tool, then I inherit their improvements.

portupgrade looks like the tool I shoould be thinking about, but I don’t want to follow their design decisions. I instinctively think portmaster has the right idea with not using an external database; maintaining pkgdb is annoying, irritating, and a whole host of other words which mean the same damn thing. There are a host of poorly documented prompts when repairing the database; stale dependency, eh? Great! What does it MEAN? I’ve always _assumed_ it was a reference to the idea that a dependency listed in the database is no longer needed, or somesuch thing; googling around can tell you, I’m sure, but the man page for pkgdb doesn’t, and if it ain’t in the man page then it’s undocumented. And that means that yes, I do consider man man to be inadequate because it tells you there a re other sections of the manual but doesn’t tell you _what_they_are_. I know what they are, they’re historically significant and everyone should know them, but man man should list them too.

I’m getting dangerously close to ranting, when I’m actually trying to document something. The aim here is to give people who’ve never written this sort of tool an idea of how the thought process goes. It’s all decisions, and no decision is correct.


Blog at WordPress.com.