On 07/30/09 14:32, Shawn Walker wrote:
> Dave Miner wrote:
>> Shawn Walker wrote:
>>> Jack Schwartz wrote:
>>>> Hi Shawn.
>>>>
>>>> On 07/30/09 11:19, Shawn Walker wrote:
>>>>> Dave Miner wrote:
>>>>>> Shawn Walker wrote:
>>>>>>> SVR4 package support is fairly minimal at the moment, and is
>>>>>>> deprecated or obsolete (not sure of the 'official'
>>>>>>> terminology). Why even support it at this point?
>>>>>>>
>>>>>>
>>>>>> Because that's the format some drivers are available in. Yes, we
>>>>>> have all sorts of ISV/IHV engineering teams fired up to get them
>>>>>> converted to IPS, but I'm favoring adoption over purity.
>>>> Yes, it will be easier for users to get started with OpenSolaris if
>>>> their rare controller card's driver can be loaded without them
>>>> having to find an IPS-packaged version of it.
>>>>
>>>> If their package behaves and has only new files and doesn't
>>>> overwrite system files, I believe there should be no problems.
>>>>>
>>>>> I figured as much, but it isn't a panacea. Is there going to be
>>>>> an escape hatch for users stuck with broken SVR4 packages?
>>>> We can check each file in the package being added, and display a
>>>> warning if that file already exists on the system. Does this sound
>>>> reasonable?
>>>
>>> That would assuage my fears greatly. There's really no protection
>>> in place to keep SVR4 packages from butchering files already on the
>>> system.
>>>
>>
>> SVR4 pkgadd will already tell you that the files are installed and
>> let you choose to continue. Don't write code to replicate that.
>
> According to the pkgadd code:
>
> 109 /*
> 110 * check to see if we can guess (via Rlist) what
> 111 * pathnames this package is likely to install;
> 112 * if we can, check these against the 'contents'
> 113 * file and warn the administrator that these
> 114 * pathnames might be modified in some manner
> 115 */
>
> ...it only checks against the contents file, so these SVR4 packages
> could overwrite files in IPS packages without the user knowing,
> correct? Or is the pkgadd code comment wrong?
I did a pkg install of SUNWcs in a test area, verified there was no
var/sadm/install/contents file, and then started a pkgadd of SUNWcsr
from onnv. 3 pages of conflicting files streamed by. So it appears
pkgadd does the right thing and doesn't use the contents file.
Thanks,
Jack
>
>>> However, it still leaves users with the issue that they may be stuck
>>> with a driver that won't be installable regardless of whether or not
>>> the check succeeds because of the architectural changes that were
>>> made in the OpenSolaris 200x releases.
>>>
>>> So is there going to be some sort of warning to users that this is
>>> not guaranteed to work correctly?
>>>
>>
>> There's no reason to scare them unduly.
>
> Hasn't that ship already sailed? The man page for pkgadd states:
>
> Certain unbundled and third-party packages are no longer
> entirely compatible with the latest version of pkgadd. These
> packages require user interaction throughout the installa-
> tion and not just at the very beginning, or require that
> their request scripts be run as the root user.
>
> I never said the message had to be alarmist, but I think the relevant
> portion of the disclaimer from the man page, at minimum, should be
> present in whatever dialog is presented to the user by the driver
> update mechanism.
>
> Won't users also be just as frustrated when an SVR4 driver package
> that installed and worked correctly under Solaris 10 won't install and
> work correctly under OpenSolaris 200x and you've given them no warning
> that it might not work?
>
> I know there is no easy answer here, but I don't think setting user
> expectations to 'it all still works' is the right answer.
>
>>> I realise that not all packages are created equal, and some will
>>> work perfectly without any issues, but I doubt that is true of all
>>> packages. There's also the issue of zones and how these SVR4
>>> packages won't be accounted for with them when it comes to
>>> driver-related utilities (as far as I know, you might want to
>>> consult Dan Price, et al.).
>>>
>>
>> Zones don't run drivers, and an IPS-based zone won't even try to
>> install non-IPS content. What's your real concern here?
>
> Yes, but if I'm not mistaken, I believe I have seen driver packages
> that will still install their relevant utilities in zones.
>
> Cheers,
