In a discussion on opensolaris-code, I mentioned that in an upcoming putback I'll be adding a new i. file for /etc/project. The question was asked if I was doing anything for IPS. My feeling is that IPS should be doing all the hard lifting... or at least it should be!
To look at the various i.* files in $SRC/pkgdefs/common_files, it does not take too long to start thinking "can't this be done better?" For every text file in /etc that has been updated over the years, there is an individual, stand-alone, script that does the same thing many times over. You'd be forgiven that this directory was a place where software design and code-reuse was prohibited. And that there's little choice but to continue copying those sins... Looking at the set of actions that pkgsend supports, it looks like the IPS folks have tried to capture the two most common changes that happen - user (/etc/passwd) and group (/etc/group). But that's not nearly enough. How many i. files are there in common_files? And how many IPS actions are there? Are we going to pretend no other file in /etc will need updating for a new package? Will we need an IPS action for each and every file that stores data? Does a new file delivered to /etc therefore need a new IPS action? Is that architecture appropriate? While the user/group action is nice and user/developer friendly, it's really an implementation of a more basic action: if a specific pattern isn't present in a file, add this line of text (possibly before or after another matching pattern.) That is all most of those i. files do. Furthermore, it would seem to me that a package should be able to supply its own action that other packages can later use. For example, if I deliver a file /etc/foo in package A and someone else develops package B that depends on A and wants to update /etc/foo, why can't B use an action that A delivers to update /etc/foo? Searching the archives seems to suggest that all discussion on this topic has stopped at users and groups - that's a start but it is not nearly enough. Darren _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
