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
