I would like to enable packrat::restore() to use Windows binaries. It seems that official CRAN mirrors do not keep old windows package binaries, hence packrat::restore() will compile from source if the snapshotted package version is no longer the most current.
The alternative of using MRAN with a manually defined CRAN snapshot date is sub-optimal as different packages were installed on different dates, hence it is hard to choose just 1 CRAN snapshot date to restore all packages.
Please assist.
Related
We have a custom Suse Linux Enterprise repository, that we want to ship to customers in the future. In there right now are a lot of different versions of the same packages, some obsolete and some needed as a dependency for other packages, so the whole repo is quite large.
I guess what im trying to do, is find a query to list all packages that have newer versions in the repository, and have no other package that needs this version as a dependency.
Is there an elegant way, to find the not needed packages ?
I have an installer for Wix which installs the program to be version I have successfully made patches to achieve the following upgrading:
1.0.0 -> 1.0.1
1.0.0 -> 1.0.2
1.0.1 -> 1.0.2
This works I've had to make new .msp files from 1.0.0 to the target build number each time. So from my understanding how the patching works behind the scenes, is that if I had initially a patch from 1.0.0 to 1.0.1 then I created a new on to go from 1.0.0 to 1.0.2, if I were to run the new patch, the old patch would be uninstalled and the new one would replace it.
If my understanding is correct then this means that patch files would continue to increase in size the more you change code, so I would like a solution to counter this, where at some point I would increment the minor version, and start the patching process over.
For example I would like to do this:
1.0.0 -> 1.0.12 could be handle with patch1.msp. Then I create a patch2.msp which would start creating patches based off of version 1.0.12. An example upgrade path might then look like:
1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x
Is there any way to accomplish this? Or would I need to reinstall with a .msi file and continue to patch from there?
First, installing a superseding MSP does not remove superseded MSPs. The superseded MSP is simply marked as superseded (inactive). Should you later remove the superseding MSP, the previously superseded MSP is reactivated.
In order to remove MSPs, you need to use the older obsolescence method, but I really don't recommend that. Not only is it difficult to manage, it also means that, for example, if you fixed a security bug in a previous patch that was removed, when the newer obsolescing patch is removed the security hole is unpatched. That's the beautify of supersedence, which has been around since MSI 3.0.
To your question, though, I don't recommend it. It's best that MSPs target the baseline. Yes, they could potentially get a little bigger, but only if you're adding content. If newer versions are just updating sets of files or other resources, an MSP targeting a single MSI should never grow larger than the base MSI (well, MSI + external CABs, since CABs are embedded in the MSPs and always should be). See https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/ for more about small update MSPs, and https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/ for how to support targeting a single baseline with minor update MSPs.
It is possible, though. You need to save the upgrade MSIs when building each patch, so when you create your 1.0.1 MSI to effectively diff against 1.0.0 to build your MSP, then when you build your next MSP you need to diff 1.0.1 against 1.0.2. These MSPs must be minor update MSPs, though. That means that the ProductVersion property is included in the patch authoring transform; otherwise, the MSI 1.0.0 + MSP 1.0.1 view won't change the ProductVersion, so MSP 1.0.2 would never be applicable. You should start to see where this gets difficult to maintain for you (not to mention forces the customer to have to install every previous version MSP, which is not a great experience for them either if they are just starting out from your RTM).
In summation, keep it easy for your customers. Just target the same baseline using the MinorUpdateTargetRTM property in the MsiPatchMetadata table of the MSP itself.
In my experience the usual path is that at some time you create a major upgrade MSI (see WiX majorupgrade element). This MSI with new ProductCode and version greater than the last patch version (e.g. 2.0.0) will upgrade all versions betweeen 1.0.0 and 1.0.12. Then you start patching based on the 2.0.0 product.
There are options in patches to patch by replacing each entire file or by binary patching of each file - I'm not sure which you are using, but obviously if you make a small patch to a huge file the patch will be larger than if the patch is a binary update to that file.
What is the best way to ensure that all developers and the build server are using the latest version of FAKE?
If a build.cmd like the one from FSharp.Data is used, the developer will not be on the latest until they delete FAKE from the packages folder or just delete the whole packages folder.
If you add FAKE as a dependency in .nuget\packages.config, your build.fsx script must include the version information and be updated each time you change versions. You will not automatically get the latest version.
With NuGet 2.8.1 you can remove the "if not exists" parts - NuGet will check (very slowly) if the latest FAKE is installed.
I tried to use RMySQL package but i get this error doing:
install.packages('RMySQL')
Warning in install.packages :
package ‘RMySQL’ is not available (for R version 2.14.2)
What can I do to use MySQL with R?
Thank you!
There is not a windows binary available for the package RMySQL. This means you will have to install this package from source and build it yourself.
At the CRAN RMySql page you will notice there is no binary available, with a link to Pre-compiled binary packages for R-2.14.x for Windows
From this page:
Packages related to many database system must be linked to the exact
version of the database system the user has installed, hence it does
not make sense to provide binaries for packages
RMySQL, ROracle, ROracleUI,
although it is possible to install such packages from sources by
install.packages('packagename', type='source')
after reading the manual 'R Installation and Administration'.
So, read the manuals, in particular R Installation and Administration, install RTools, and then use:
install.packages('RMySQL', type='source')
After installing Rtools, from the RMySQL CRAN page grab the source from the Package source: link to ensure that you have the latest version. Then read the information in the INSTALL file that comes with the package (or find the same info at the Installation: link on the aforementioned CRAN page).
The main problem that most people have is following outdated information on the internet that pertains to older versions of RMySQL rather than using the instructions that come with the package itself.
After spending 10Hours,I followed Arne's instructions and Willem's comment from here:
http://www.ahschulz.de/2013/07/23/installing-rmysql-under-windows/ and it worked like magic.
I experienced some difficulty with installing RMySQL package in R, twice this year. I haven't used it, yet. To help me in getting around the known additional problems, I followed the steps I found in these two articles:
Installing RMySQL under Windows
Vanderbilt University RMySQL page
First you need to download, install and configure MySQL to work with Windows. Next, you will have to create or edit a file called Renviron.site, and add the variable MYSQL_HOME to your default environment, and other tricky tweaks that may have worked for other people, but have not worked for me.
It appears that running RMySQL on Windows is not advised; there are other packages that you can use to get R to work with MySQL. I've been checking out R bloggers, R Studio Support and the R Help Mailing List, for ways to get around the problem.
Although they're useful resources, there is no guarantee that the troubleshooting steps will work for everyone. You can try following them to install RMySQL package, and if they work you should be able to use the package with R.
I have been developing (a somewhat complicated) app on core python (2.6) and have also managed to use pyinstaller to create an executable for deployment in measurements, or distribution to my colleagues. I work on the Ubuntu OS.
What has troubled me is in upgrading the versions of numpy or scipy. Some features I need are in 0.9 and I'm still on 0.7. The process of upgrading them, or matplotlib, for that matter are not elegant. The way I've upgraded on my local machine was to delete the folders of these libraries, and then manually install the newer versions.
However, this does not work for machines where I do not have root access. While trying to find a workaround, I found ActivePython. I gave it a quick try and it seems to use PyPM to download the newest scipy and numpy to its custom install location. Excellent! I don't need root access and can use the latest version of the libraries.
QUESTION:
If there are libraries not available on the PyPM index with ActivePython, how can I directly use the source code of those libraries (example wxpython) to include into this installation?
How can I use pyinstaller to build an executable using only the libraries in the ActivePython installation?