Yup, that captures it correctly.
IPS cannot replace SVR4 packages without this issue
taken care of.
I'd call it a P1. Or else the support folks are in
for a fun time when it comes time to "patch" one of
the many /etc text files with IPS.
And to answer Danek's question about whether or not
a generic file assmebler is required - look in
$SRC/pkgdefs/common_files and tell me that one isn't.
Darren
Ed McKnight wrote:
http://defect.opensolaris.org/bz/show_bug.cgi?id=3938
Darren Reed wrote:
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
