Jonathan Edwards wrote: > (1) Slowness .. (don't get me wrong - it's gotten better) .. [pkg defects > 1949, 5225, 10706]
(All search performance bugs.) 1949 is fixed. As for slower than other packaging systems, yes, we do want to get this faster, but, we may never get it to the speed of SVr4, mostly because we have a far more structured search than it does. Brock's by no means finished with enhancing search, but at the moment, it's a low priority. > (2) Decent pre/post-install methodologies: > I do understand the desire to containerize this sort of thing within SMF, > but i do not believe that there is a current mechanism defined to > start/stop SMF services around a package installation Why do you not believe that exists? See pkg(5), in the section "Actuators". > .. also somewhat problematic for driver installs, or device rebuilds > (3) Problems when 2 packages might claim the same file, link, or may > depend on the same configuration file .. [pkg defects 3822, 1820, > 2369, 3849, 3920, 3925, 9005, 9294] Yeah, these suck, but mostly as long as you don't try to uninstall these packages, the OS works fine. We've a couple of competing solutions partially implemented; hopefully we'll have a chance to flesh them out and get something back for the next release. > (4) No formal standalone package format defined .. [pkg enh 2152, 7067] Yup. We're working on it; it needs to get fixed for release, but given that you can pkgrecv a package into a repo format and fire up a repo on it after sneakernetting it wherever you want, it's not our highest priority item. > ok .. so I've got a pretty good understanding of python, C, storage, > filesystems and the like .. have built large installation and deployment > systems for many customers, worked with a variety of package installers > and methodologies over the years (and even built a few of my own) - i'd > be happy to help prototype or possibly redesign some of the above .. how > can I help? or rather - where don't you need help? You can pick up bugs, I suppose. A lot of the bugs we have look simple but have some nasty tendrils that require enough thinking that we haven't actually picked them up. But if you're interested, go through the list, think about a solution, propose it on pkg-discuss, and if you get positive feedback, work on a fix. I don't think we need help with design at the moment, and I don't want to get a flood of occasional implementors, either, as that's just going to take more time to manage and ultimately reduce the amount of real work we get done. Someone with patience who's committed to high quality code and interactions with the team, however is always welcome. Danek _______________________________________________ opensolaris-discuss mailing list [email protected]
