On Thursday, 14 May 2020 23.58.02 WEST I?aki Ucar wrote:> But we still have to rebuild the packages anyway, and this setup > doesn't force us to actually rebuild them, nor the user to update > them. So a user could end up with R major.minor and a bunch of > packages installed in some major.minor-1 path that are just junk. Or > the other way around: a bunch of packages updated under major.minor+1 > with a previous version of R.Honestly my point here was for consistency with the user settings. If you have per version directories for users why not to do the same for the system?> I mean, +1 to less boilerplate for packages, but changing the release > + the ABI specification is not a big deal and solves those issues. For > me, having a path with full version specification only makes sense if > there is more than one version installed at the same time, like > Python.That would also be a nice side effect. :-) -- Jos? Ab?lio
On Fri, 15 May 2020 at 11:58, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote:> > On Thursday, 14 May 2020 23.58.02 WEST I?aki Ucar wrote: > > But we still have to rebuild the packages anyway, and this setup > > doesn't force us to actually rebuild them, nor the user to update > > them. So a user could end up with R major.minor and a bunch of > > packages installed in some major.minor-1 path that are just junk. Or > > the other way around: a bunch of packages updated under major.minor+1 > > with a previous version of R. > > Honestly my point here was for consistency with the user settings. > If you have per version directories for users why not to do the same for the > system?The rationale behind the user settings is that the user dir is not controlled by the system, so versioning it is the only way to avoid breakage. For the system library, there are better tools to prevent that.> > I mean, +1 to less boilerplate for packages, but changing the release > > + the ABI specification is not a big deal and solves those issues. For > > me, having a path with full version specification only makes sense if > > there is more than one version installed at the same time, like > > Python. > > That would also be a nice side effect. :-)Are you suggesting that we should maintain several versions of R at the same time? I don't think we want or should go down that path... :D -- I?aki ?car
On Friday, 15 May 2020 11.33.26 WEST I?aki Ucar wrote:> The rationale behind the user settings is that the user dir is not > controlled by the system, so versioning it is the only way to avoid > breakage. For the system library, there are better tools to prevent > that.Do you know the difference between theory and practice? :-) In theory they are equal but in practice... :-)> > > I mean, +1 to less boilerplate for packages, but changing the release > > > + the ABI specification is not a big deal and solves those issues. For > > > me, having a path with full version specification only makes sense if > > > there is more than one version installed at the same time, like > > > Python. > > > > That would also be a nice side effect. > > Are you suggesting that we should maintain several versions of R at > the same time? I don't think we want or should go down that path...No I am not suggesting that. :-) If we take the example from python where I have installed versions from python 3.4 to 3.9 (that is yet in alpha stage). # rpm -qf /usr/bin/python3.? python34-3.4.10-10.fc32.x86_64 python35-3.5.9-1.fc32.x86_64 python36-3.6.10-2.fc32.x86_64 python37-3.7.7-1.fc32.x86_64 python3-3.8.2-2.fc32.x86_64 python39-3.9.0~a6-1.fc32.x86_64 The only version where I have python packages installed is for 3.8 (since I am using Fedora 32 - as it can be seen above). That allows me to test the base version for python without having to compile every time and every where I want to use it. And although it was not my initial motivation but you probably saw the discussion today on R-devel (Rd) about people not testing the versions alpha, beta and rc from r-devel. A versioned system path would allow to test this more easily. -- Jos? Ab?lio