Menu
▾
▴
scrollkeeper-devel
|
From: Laszlo K. <las...@su...> - 2001-06-27 13:40:27
|
Hi All, I am looking into implementing the relocatable package support according to this algorithm: http://www.geocrawler.com/archives/3/6429/2000/11/50/4678568/ First, I think we should rename the scrollkeeper-update-identifier script to scrollkeeper-update-url. Summarizing it we have the following features: 1. Update the url in one OMF file if an absolute url path is specified. 2. Update the url in one OMF file if only a base filename in the OMF file and a directory name (where the doc resides) is specified (recursive search down the dir for the doc). 3. Update the url in one OMF file if a relative filename in the OMF file and a directory name (where the doc resides) is specified (append the relative path to the dir). There would be one more needed: 4. Update the url in a set of OMF files in the same subdirectory structure with urls from docs specified by a directory only. Both the base filename (2) and the relative filename (3) should work in this case. The user should be able to do something like this: scrollkeeper-update-url $prefix/share/omf/scrollkeeper $prefix/doc/scrollkeeper and this should do everything they need. This can become quite complicated to be used together with scrollkeeper-preinstall, it will need a good documentation. Thoughts? Laszlo |
|
From: Dan M. <d-...@uc...> - 2001-06-27 20:26:35
|
On Wed, 27 Jun 2001, Laszlo Kovacs wrote: > First, I think we should rename the scrollkeeper-update-identifier > script to scrollkeeper-update-url. Good point. We are only updating the one attribute of the element. > There would be one more needed: > > 4. Update the url in a set of OMF files in the same subdirectory > structure with urls from docs specified by a directory only. Both the > base filename (2) and the relative filename (3) should work in this > case. This would be the preferred way to do things. > The user should be able to do something like this: > > scrollkeeper-update-url $prefix/share/omf/scrollkeeper > $prefix/doc/scrollkeeper > > and this should do everything they need. :) > This can become quite complicated to be used together with > scrollkeeper-preinstall, it will need a good documentation. Hmm... I think it would be helpful to figure out a little more about what information we have access to for passing to the post-install script. We can either have the OMF file originally contain the full non-relocated path. Or, it could have the part of the path without $prefix and then sk-update-url could just add the prefix. Or, ... I think the best solution would require that the post-install script have access to the unrelocated and relocated prefixes. Then we would do everything exactly as we did before and if somebody wants to make it relocatable they just add a post-install script which basically just does a search and replace on the prefix strings. So, does anybody know whether we will have access to both of the prefixes (before and after) in the packaging systems we care about? Dan |
|
From: <las...@Su...> - 2001-06-28 13:20:08
|
> > There would be one more needed: > > > > 4. Update the url in a set of OMF files in the same subdirectory > > structure with urls from docs specified by a directory only. Both the > > base filename (2) and the relative filename (3) should work in this > > case. > > This would be the preferred way to do things. > Hmm... I think it would be helpful to figure out a little more about what > information we have access to for passing to the post-install script. We > can either have the OMF file originally contain the full non-relocated > path. Or, it could have the part of the path without $prefix and then > sk-update-url could just add the prefix. Or, ... > > I think the best solution would require that the post-install script have > access to the unrelocated and relocated prefixes. Then we would do > everything exactly as we did before and if somebody wants to make it > relocatable they just add a post-install script which basically just does > a search and replace on the prefix strings. We should have access to the target root directory to be used in order to build the parameters of scrollkeeper-update-url. On further thinking maybe we are overdoing the relocation support. What about the following: - The preinstall script is either used to set an absolute path or a relative one to $prefix as url - If an absolute path is set then that is the path, no postinstall change is done - If a relative path is used than it should form a correct full path together with $prefix This would be the internal algorithm and the only interface provided for postinstall url update would be: scrollkeeper-update-url $omf_dir $prefix This sounds simple so maybe I missed something, but anyway what do you think? Is there any situation this wouldn't cover? We could even get rid of preinstall if we follow this as those absolute and relative paths mentioned above could be hardcoded in the OMF file. Only that if the developer wants to change the general directory layout of the project they will have to edit the OMF files while if scrollkeeper-preinstall is still there they are OK with editing Makefile.am only. Laszlo |
|
From: Dan M. <d-...@uc...> - 2001-07-02 17:50:41
|
A little bit of browsing around linux.redhat.rpm turned up RPM_INSTALL_PREFIX as the variable which stores the prefix which will be used. I'm not sure if PREFIX is overwritten, but even if it is it should be easy enough to store it as another variable name. So, let's assume we always have access to the default and relocated prefix. (Here I'm assuming other packaging systems are at least as good as RPM ;) I think two main systems have been proposed: 1) Do not include the prefix in the OMF file until post-install time. We won't need the pre-install step. At post-install time, the scrollkeeper-update-url script is run which modifies the OMF files and inserts the prefix into the URLs. In this case, relocatable and non-relocatable packages are handled identically. 2) Include the prefix in the OMF file with scrollkeeper-preinstall, as we do now. For relocatable packages only, one adds an additional post-install call to a script, scrollkeeper-update-url, which replaces the unrelocated prefix with the relocated one. In this case, unrelocated and relocated packages are still handled pretty much the same except that one (simple) extra line is added to the spec file. I don't see any technical problems with either of these approaches. (Does anybody?) So, I'm inclined to use whichever one is simplest for package authors to understand and implement. I think #1 is probably simpler even though it introduces a second post-install script, since it gets rid of scrollkeeper-preinstall and uses the same method for both relocatable and non-relocatable packages. We could allow people to choose either of the two, but I think that just complicates things. Dan |
|
From: <las...@Su...> - 2001-07-09 12:12:52
|
Dan Mueth wrote: > > A little bit of browsing around linux.redhat.rpm turned up > RPM_INSTALL_PREFIX as the variable which stores the prefix which will be > used. I'm not sure if PREFIX is overwritten, but even if it is it should > be easy enough to store it as another variable name. So, let's assume we > always have access to the default and relocated prefix. (Here I'm > assuming other packaging systems are at least as good as RPM ;) > > I think two main systems have been proposed: > > 1) Do not include the prefix in the OMF file until post-install time. We > won't need the pre-install step. At post-install time, the > scrollkeeper-update-url script is run which modifies the OMF files and > inserts the prefix into the URLs. In this case, relocatable and > non-relocatable packages are handled identically. > > 2) Include the prefix in the OMF file with scrollkeeper-preinstall, as we > do now. For relocatable packages only, one adds an additional > post-install call to a script, scrollkeeper-update-url, which replaces the > unrelocated prefix with the relocated one. In this case, unrelocated and > relocated packages are still handled pretty much the same except that one > (simple) extra line is added to the spec file. > > I don't see any technical problems with either of these approaches. (Does > anybody?) > > So, I'm inclined to use whichever one is simplest for package authors to > understand and implement. I think #1 is probably simpler even though it > introduces a second post-install script, since it gets rid of > scrollkeeper-preinstall and uses the same method for both relocatable and > non-relocatable packages. > > We could allow people to choose either of the two, but I think that just > complicates things. > > Dan I prefer (1), it is simpler to implement and simpler to use. Laszlo |