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
On Sat, 16 May 2020 at 00:49, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote:> > 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.Sorry, but I'm not sure I'm following you. How does having /usr/lib64/R/library as system library prevent you from testing r-devel? But anyway, I'm only saying that, independently of the path, we can benefit from the R(ABI) virtual provide, as Python does. -- I?aki ?car
On Saturday, 16 May 2020 00.38.34 WEST I?aki Ucar wrote:> Sorry, but I'm not sure I'm following you. How does having > /usr/lib64/R/library as system library prevent you from testing > r-devel?First the context, we are speaking of srpms. Use case: you want to test a pre-version of R before it is released and you want to do it using dnf while not having to de-install the current version, with all its libraries. Since the purpose is both to install and test both r-devel and the rpm packages the goal should be that the spec file should be as close as possible to the final spec file. What I am saying is that by experience it is easier to test and adapt a spec file if only a small number of conditionals are needed to use the current spec file. As far as I remember, from Miro's messages in fedora-devel, that is what is being done in the python packages. That is also what I have done for other packages, although not a language, like lyx. I hope that now it makes sense, -- Jos? Ab?lio