I spent some time during the last hackathon, talking to various people over where we're going.
I'm a bit afraid that people are going to see the ports/package framework as "not invited" (because some of the subsystems of OpenBSD are not exactly oustide friendly) Right now, I got one student directly working with me on the tools, and I must say it is a good thing: I have waaaay too many idiosyncrasies. And I'm trying to get better at documenting ?` So where are we going ? there are lots of pieces missing, some of them trivial, some really annoying. - the level of testing is abysmal. I would really like for someone to have fun with regress and make it manageable. Right now, it's a pain ! More tooling to make pkg_add "fully" regression testable would be very helpful. - likewise register-plist needs some tests. I have made some progress in options to make that happen. - I would love to get some Devel::Cover stats... zero progress about this during this week (well, the main progress was that it does not work) - I converted ALL my code to perl 5.36. Having signatures is a HUGE change, not wrt actual code, but with readability. It makes perl code look like "other" programming languages, in a good way, thus making it sooo much easier for new people to get in. As for the actual code changes: - we need more code to deal with "global state", mainly /etc/rc changes and messages. Those files are going to move around, which means it's going to be GLOBAL state, because it can move from package to package. I would really really love to have regress test cases first. - we still need better Vstat code that deals with symlinks. There's one test that actually fails... and writing more tests should be simpler. - the code dealing with "old libs" is still incredibly ad-hock and needing some love. - there's something fishy in pkg_create wrt dependency handling... figure it out, AND make it work with tags as well. - fragments building is oversimplified, that's the main thing holding back ocaml "smart fragments". - texlive wants some love. That one is pretty much mine: a bit of targets in bsd.port.mk, a bit of "hints" code in update-plist, and also the ability to say "oh, don't package this, it's already in". Nothing really difficult, it's just that texlive is large... - displays and codes from pkg_add/pkg_info. The main culprit right now is FETCH_PACKAGES, it could be better. - "libsets". Updating wantlibs is really a pain for big changes. I have a keyword called libset to deal with that. It requires changes to bsd.port.mk and to pkg_add. Simply put: a libset would have a version and say "we need those libs to work". If a libset got bumped, then we wouldn't say the affected libs are a problem if they change ! This is mostly a question of writing the code. - lib-depends-check: the script AND its dependent libraries need a lot of clean-up, so that an average person can understand them. Then we can deal (probably) with subdirectories (which we don't) - dpb changes: the "files needed" change. I have all the pieces to figure out which files and directories a given build requires: in the ports tree, MAKEFILES_LIST + PKGDIR + PATCHDIR + FILESDIR + package + distfiles would be enough. I need to actually provide this. This would enable TWO huge things: -> disconnected builds, with a cluster that doesn't use nfs, but runs openrsync instead -> separate builds into separate chroots (roughly 6000+ links per build) - regress tests: should be much easier now that diskspace is (mostly) not an issue - roaching while fetching: the main part would be to figure out which part of roach we actually need to plug in after fetch. Having a sqlite database is actually a huge hindrance. dpb could output "decent" logs, and it should be easy to coerce them. I probably missed some entries, but this is what occupies my ports/pkg* thoughts. Help welcome. Not perl solutions NOT welcome.
