On 11/21/05, Hans Reiser <[EMAIL PROTECTED]> wrote: > Vitaly Fertman wrote: > > >On Monday 21 November 2005 10:09, Hans Reiser wrote: > > > > > >>Philippe GramoullИ wrote: > >> > >> > >> > >>>Hello, > >>> > >>>On Sun, 20 Nov 2005 05:07:23 +0100 > >>>rvalles <[EMAIL PROTECTED]> wrote: > >>> > >>> | When I run make install on something and haven't specified a prefix on > >>> | configure, I expect /usr/local to be used. If I wanted /, I'd have > >>> | specified that on configure time. If it installed in / by default, it > >>> | would, often, hit the "sacred package-system managed area" of the VFS > >>> | tree annoying people like me to a very great extend, so please don't. > >>> > >>>While i totally agree with you for standard packages, well i based my > >>>choice > >>>on actual experience of the last past six years of use with reiserfs V3. > >>> > >>>I can't remember how many times i heard Namesys team say " Install the > >>>latest > >>>& greatest reiserfsck", how many times distro thought they knew > >>>reiserfsprogs > >>>internals better than Namesys and customized it to the point where it would > >>>eventually break. > >>> > >>>Of course, i can live with a manual install of reiser(fs|4)progs, so i > >>>don't > >>>really mind, but talking of support, it can make quite a difference to > >>>Namesys > >>>in terms of support, and annoyance with bug reports that could have been > >>>easily > >>>avoided. > >>> > >>> > >>> > >>> > >>Ok, I propose the following: search the standard locations for where it > >>is currently, tell the user, ask the user if they want to rename those > >> > >> > > > >the proper service is already done in package managers. if one needs it, > >he can use one of them. > > > > > > > >>versions to *.old if the install of the new one succeeds, and then > >> > >> > > > >this breaks the installed software consistency and may screw the package > >manager up... > > > > > Sigh, good point, ok, well then at least warn the user about them. > > > > > > >>prompt for the install location with /sbin as the suggested default. I > >>think that unlike other user installed programs, fsck does not belong in > >>/usr/local. I think Philippe's point that old versions are dangerous is > >>quite valid. > >> > >> > > > >install to the system default through a system package manager; > > > >install to the local default from source to not break the system installed > >software consistency; > > > > > So the reason for not installing to /sbin is to avoid messing up the > package manager? I regret to say it makes sense. If that is the > reason, then warn the user please about old versions left intact, and > suggest they be removed, and prompt the user for the path to install to > and remind them to update their $PATH. >
The problem is that some package managers might make reiser4progs a "base" package, which removing will emit a loud warning that it might break your system. That said, anyone installing a custom reiser4progs may or may not be supposed to have the knowledge to work around it. It'd be like the installing java mess all over again [times two] -- except for one difference... Java isn't essential. Reiser4progs could be. It might be easier to make a pseudo-package representing the program (e.g. the way Sun's JRE is "converted to a package" in Debian Sarge, as well as the way older versions used an empty package file to satisfy depends in Debian Woody; reiserfs would have a fake package in the package manager when installed from source) or to actually put package building scripts for package-handling distros in the source package (or use something like checkinstall, provided it doesn't conflict too bad). [You can also did what Debian did with it's 'kernel-package' system; it provides a package specially designed for converting a custom kernel into a package, so similarly, a packaging-tool specific to that distro could be put in the distro. This lets users use any kernel source without having to use a debianized source and still have a kernel package to install at the end; so you can use the latest and greatest Reiser4Progs and the Debian package manager without having to wait for a debianized package. Same or similar applies for other packaging distros.] *sigh* How complicated... -- ~Mike - Just my two cents - No man is an island, and no man is unable.
