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 >
