Right - after all it is just software and anything is possible :)
We don't even need to all agree as long as the packaging framework
supports it (without breaking existing functionality, of course)
for those that want to use it :) It would be nice if everybody
adapted the same practice, though, but I guess that might vary?
I absolutely agree it would be nice to provide and support a fixed
path through soft links for the user's convenience. This could e.g
be done along the line of Option 2 below implemented via a package
with a never changing name (but of course new version revs).
That would require
1. adding soft link package with SVR4 package class action
script (preferably standardized) to ensure preservation
of soft links: trivial, only package design, and all up
to the package maintainer;
2. a simple [re]implementation of a corresponding IPS tag/
attribute and its underpinnings; and
3. updates to SVR4->IPS translation tools (optional, but
recommended).
Once that IPS framework addition is in place, products/packages
can adapt at their own leisure.
Anyone want to design, implement and ARC that for 2008.11? :)
(of course, this is only necessary if you care to conservatively
preserve soft links that are shared across packages)
-- Lars
Sriram Natarajan wrote:
> Seema - The response still suggests that it is technically possible to
> resolve it - if we all want to . I guess, I am still looking for answers
> as to do we all want to resolve this ? If yes, how we want to ?
>
> - Sriram
>
> Seema Alevoor wrote:
>> Sriram,
>>
>> Below is Lars' response posted to pkg-discuss, which explained about the
>> symlinks issue.
>> HTH.
>>
>> -- Seema.
>>
>> ----------------------
>> Jumping in a little late... Most interesting bit at the end.
>>
>> -- Lars
>>
>> Danek Duvall wrote, On 07/23/08 08:36 AM:
>> > > On Wed, Jul 23, 2008 at 11:49:02AM +0530, Sunanda Menon wrote:
>> > >
>> >> >> The question is since the customer who has previously installed MySQL
>> 5.0
>> >> >> will have his /var/mysql/data pointing to /var/mysql/5.0/data which
>> has
>> >> >> real time data .Now if I install 5.1 packages the links will change
>> >> >> pointing to 5.1 which he may not be ready for as he is caught unaware
>> .
>> >> >> How do I communicate to the user that his links will be overwritten ?
>> > >
>> > > At the moment, release notes are your best bet. Or don't change the
>> links.
>> > > You have a real dilemma trying to support a product whose file format
>> > > changes every time you upgrade. If that didn't happen, then the data
>> > > directory wouldn't have to be versioned, and you wouldn't have the
>> problem.
>> > > Or are the 5.0 and 5.1 database formats compatible?
>> > >
>> > > Is the intent to have mysql 5.0 and 5.1 on the system at the same time
>> (as
>> > > well as 4.0)?
>>
>> Since users may deploy on 5.0, need to test on 5.1 or 6.0 and then migrate,
>> multiple versions will need to coexist. You could have multiple deployments
>> on same server, too. Formats may change, even in minor version upgraded,
>> I'm told.
>>
>> Due to the complexity of and risk connected to maintaining the soft links,
>> we are considering dropping them altogether (behave like e.g postgres).
>>
>> 4.0 will be removed once SER/SIP proxy verify they work with 5.x (6631906).
>>
>> > > The ARC case for mysql5 stated that the next version of mysql we
>> intended
>> > > to ship was going to be 6.0, which is why the packages (although not the
>> > > directories) were named as "5" rather than "50". In addition, the case
>> > > stated that the intent was to have the links always point to the latest
>> > > version of mysql. So there needs to be a bit more clarity about what
>> the
>> > > intent is now, six months later.
>>
>> 6.0 will not be here for quite some time yet. 5.1 is quite an upgrade
>> over 5.0 and we should definitely get that out to users.
>>
>> For stability reasons, having the links point to the latest version is
>> not a good design choice. If present, they should be behave very
>> conservatively as not to interfere with any running server instances.
>>
>> > > At any rate, if you want for a fresh install to point to 5.1, but for
>> > > existing links to continue pointing to 5.0, then I believe that the tag
>> > > "preserve=true" will prevent the link from being overwritten. I don't
>> > > think we do that for any symlinks right now, but there's no reason I can
>> > > think of that it shouldn't work.
>>
>> This is what Sunanda was thinking of, I believe.
>>
>> > > But I'd rather that you state the exact behavior you need/want, and we
>> can
>> > > figure out a mechanism to support that if appropriate, rather than
>> trying
>> > > to triangulate the path forward based on a vague explanation of the
>> desired
>> > > behavior and a vague understanding of what might or might not be
>> possible
>> > > now, or in the future.
>>
>> The issue is:
>>
>> SUNWmysql5* delivered soft links a la /usr/mysql/bin -> 5.0/bin and
>> /var/mysql/data -> 5.0/data. Upon istalling SUNWmysql51* or later,
>> any existing such soft links should not be touched as that could
>> interfere with running server instances and otherwise surprise the
>> non-sysadm MySQL user/adm...
>>
>> How can this be handled for both SVR4 and IPS packages?
>>
>> Option 1:
>> * drop the soft links altogether.
>>
>> Option 2:
>> * add SVR4 class action script (e.g i.preservesoftlink) for
>> soft links similar to the existing and popular i.preserve
>> * make the IPS tag/attribute "preserve=true" also preserve
>> non-file objects (or add new "preservesoftlink=true":
>> "preserve" attribute is listed only under File Actions
>> in pkg(5) today)
>> * make relevant tools (solaris.py still?) automagically
>> translate i.preservesoftlink into the new preserve=true
>>
>> (or other rather inedible options)
>>
>> Option 2 would be best if made possible very soon (SVR4 bit
>> is trivial on us), otherwise we will have to go with Option 1.
>>
>> Comments?
>>
>> ---
>>
>> Another problem is of course:
>> * 5.0 installs soft links
>> * 5.1 install does not touch those
>> * 5.0 is uninstalled
>> * soft links are gone
>> * 5.1 user is miffed
>> This could have been handled with a separate package with no version
>> identifier as part of the name, e.g SUNWmysql-softlinks (ok, bad name),
>> that would carry only those soft links and behave as Option 2 above.
>> Not sure this - managing packages, an admin/root user task - is a very
>> good way to handle such user conveniences like these soft links, though...
>> ;)
>>
>> -- Lars
>> ---------------------------------
>>
>>
>>
>> Sriram Natarajan wrote:
>>
>>> Sunanda Menon wrote:
>>>
>>>> Sriram Natarajan wrote:
>>>>
>>>>> Sunanda Menon wrote:
>>>>>
>>>>>> Sriram Natarajan wrote:
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>> I was wondering, if I can hear every one's thoughts as to should
>>>>>>> we deliver a symbolic link of apache, php and mysql binaries (at
>>>>>>> least some of the most commonly) used under /usr/bin ? For example,
>>>>>>> some of the commonly used binaries like ab, apxs, httpd,
>>>>>>> httpd.worker, php, php-cgi, mysql, mysqladmin should have a
>>>>>>> symbolic link under /usr/bin ? One argument for having this under
>>>>>>> /usr/bin is they are easy to access and customer clearly knows
>>>>>>> about this ? Currently, none of this are delivered under /usr/bin
>>>>>>> and users are expected to set /usr/<component>/<version> in their
>>>>>>> PATH before using these. Do we still follow the same pattern ?
>>>>>>>
>>>>>>> If we are going to create symbolic link, then what will be the
>>>>>>> expected behavior if a newer version of these components are
>>>>>>> integrated ? Will the newer version of components simply over write
>>>>>>> the symbolic links to point to the newer version ?
>>>>>>>
>>>>>>>
>>>>>> The new version simply overwrites the symbolic links .
>>>>>> Thanks for starting this thread ,even for MySQL this was a big
>>>>>> requirement and we did away with the symbolic links in 5.1.
>>>>>>
>>>>>>
>>>>>>
>>>>> can u elaborate as to what does it mean when you say 'we did away'..
>>>>>
>>>> For 5.0 we had usr/mysql/bin ---> /usr/mysql/5.0/bin ,but in 5.1 we
>>>> have kept it as binaries being installed only in /usr/mysql/5.1/bin
>>>> and the symbolic link doesn't get created as part of the package .
>>>>
>>>>
>>> Why did you guys decide to do this way ? Considering that users are now
>>> used to seeing some of the mysql binaries under /usr/bin and suddenty
>>> yanking it out does not seem the right thing to do. I am sure, you guys
>>> have your reasons but want to know as to
>>> a) why you did not keep up with the practice of leaving the useful
>>> mysql binaries under /usr/bin as you did with MySQL5.0 in OpenSolaris
>>> 2008.05 ?
>>> b) will our customer not wonder as to why we suddenly yanked it out ?
>>> c) should all relevant components not follow the same practice - I see
>>> that PostgreSQL 8.2 / 8.3 does not create any symbolic links .Is this
>>> the accepted practice now ?
>>>
>>
>>
>>> - Sriram
>>>
>>>>>>
>>>>>>
>>>>>>> thanks
>>>>>>> sriram
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>
>>>>>>> webstack-discuss mailing list
>>>>>>> webstack-discuss at opensolaris.org
>>>>>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> _______________________________________________
>>>
>>>
>>> webstack-discuss mailing list
>>> webstack-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>>
>> _______________________________________________
>>
>>
>> webstack-discuss mailing list
>> webstack-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
>>
> _______________________________________________
>
>
> webstack-discuss mailing list
> webstack-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
