Hi Bart,


I'm not sure if I can send this message directly to you, but I have some follow 
up question for the below topic(Message 6).

If you read it, please kindly reply this.



>This is actually happening because of a different mechanism.  When IPS updates 
>a package, it only installs the difference between the two packages.

>For example, if the latest driver update only changes a manual page, only that 
>file is updated - the rest of the files and actions are left alone.



I'm having trouble to fully understand this.

So, I give you a situation, please give me the result.

if I install pkgA(ver 1.0), then remove a file installed from pkgA, then 
install pkgA(ver 2.0), pkgA(ver 2.0) = pkgA(ver 1.0) + some extra files.

then, will the deleted file come back after install pkgA(ver 2.0)?

If it only installs the difference between the 2 packages, this file should not 
come back, only those extra files will be copied to the system.

But when I tested my package, I found that the deleted files will be copied 
back to the old position. Isn't this betray IPS's mechanism?





>In the case you're describing, the user has rem_drv'd the driver - but IPS 
>doesn't know this.

>When the user updates the package, the the driver action in the new package is 
>exactly the same as the driver action in the old package, and so IPS doesn't 
>re-install the driver.



Even though the driver action in the new package is exactly the same, but the 2 
drivers have different versions. Even though the driver names are the same, but 
they have different description. I felt that the old driver is replaced by the 
new driver, but the corresponding driver action(add_drv) is not done.

So, can I say that, because driver action(add_drv) are the same, it's not 
executed.

but because the 2 drivers are different, the new driver replace the old driver?



And do you have any document from Oracle that explains this IPS mechanism? I 
would really appreciate to have a look.



Message: 6

Date: Thu, 24 Jan 2013 09:43:19 -0800

From: Bart Smaalders 
<[email protected]<mailto:[email protected]>>

To: [email protected]<mailto:[email protected]>

Subject: Re: [pkg-discuss] Question about Administrative Customization

      in IPS

Message-ID: <[email protected]<mailto:[email protected]>>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed



On 01/24/13 07:22, Bing Bai wrote:



> From a discussion earlier

> http://mail.opensolaris.org/pipermail/pkg-discuss/2012-May/029056.html

>

> I understand there's a mechanism in IPS that if a SMF service in old

> package is removed by user, it'll be counted as administrative

> customization.



> Then, if user install new version package, this service won't be

> enabled because the previous removal operation is detected.

>



This is correct; this is implemented in SMF and is the desired behavior.



> Now we have observed that, if we remove drivers that added by package,

> then install newer version of the same package. the drivers can't be

> added back. Which means that driver deletion is also counted as

> administrative customization.



This is actually happening because of a different mechanism.  When IPS updates 
a package, it only installs the difference between the two packages.  For 
example, if the latest driver update only changes a manual page, only that file 
is updated - the rest of the files and actions are left alone.



In the case you're describing, the user has rem_drv'd the driver - but IPS 
doesn't know this.  When the user updates the package, the the driver action in 
the new package is exactly the same as the driver action in the old package, 
and so IPS doesn't re-install the driver.



>

> My question: is there any way to force IPS to add driver regardless

> user's intervention?

> In our case, after package installed, it's possible that its drivers

> will be removed with rem_drv, but we want those drivers back after

> installing the higher version of that package.



This is awkward, because of the design of the *drv commands is quite fragile 
and it is easy for things to go wrong. First of all, my suggestion is to tell 
the users: Don't do that :). My second suggestion is that the user use pkg fix 
on the package to restore coherence between the packaging system's view of the 
world and the *drv subsystem.



I've just tested this and it appears to work just fine.



We won't make this an automatic behavior, because the administrator did the 
rem_drv for a reason, and blindly overriding his configuration changes in that 
manner is likely to lead to more serious problems.



- Bart



--

Bart Smaalders                Solaris Core OS

[email protected]<mailto:[email protected]>     
http://blogs.oracle.com/barts

"You will contribute more with Mercurial than with Thunderbird."

"Civilization advances by extending the number of important

  operations which we can perform without thinking about them."





------------------------------


Best Regards!
Bing

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to