i am using Fedora 24. For my thesis, i have to build BlueZ from the source, because I need the experimental features.
Now, what is the best practice? Do I have to remove BlueZ from the OS before I can reinstall it from the source? When i try to remove bluez with dnf, he wanna also remove httpd and other applications as dependencies.
Thanks
Best practice is probably to rebuild the RPM. We have bluez 5.39 in Fedora 23 (and 24) currently — this is one minor release behind the latest. If you need the newest, you could grab it from Rawhide, Fedora's development branch.
Then, modify the spec file to enable the experimental features you need (presumably in this case by putting --enable-experimental on the %configure line.
When you modify the specfile, add something like .experimental.1 to the end of the Release: field. That way, it will be counted as a newer update, and you can dnf update bluez-5.39-1.fc23.experimental.1.x86_64.rpm. (Update that final .1 whenever you make a change, as a form of rudimentary version control.) Then, use the DNF versionlock plugin to make sure updates don't override it, and when new versions come out, update at your leisure.
Related
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
I want to have unattended-upgrades installed on my server and I want to edit the default config. I like to receive mail to confirm an upgrade, I know where to change it in config files.
andschwa/unattended_upgrades doc clearly says that puppetlabs/apt can manage unattended upgrades but there is nothing said in the doc.
Can I have some help to configure unattended-upgrades with puppetlabs official apt module ?
I know that there is several modules to manage unattended-upgrades but I want to be sure that it is not possible with puppetlabs/apt before adding another module like puppet/unattended_upgrades as it is said that it is not available for debian 8.
Thanks
andschwa/unattended_upgrades doc clearly says that puppetlabs/apt can manage unattended upgrades but there is nothing said in the doc.
The functionality was removed from puppetlabs-apt in version 2.0.0 (now 4.0.0), and moved into puppet-unattended_upgrades (the Vox Pupuli module).
I want to be sure that it is not possible with puppetlabs/apt before adding another module like puppet/unattended_upgrades as it is said that it is not available for debian 8.
This looks like a mistake in the metadata only that's been fixed in git since the latest release (2.2.0). The code to handle Debian 8 (Jessie) appears identical in the released version to git, so I'd say you can and should use this module to manage unattended-upgrades.
One of my company's products requires QuickTime. Our installer (made with InstallShield) at the moment attempts to install QuickTime automatically. Unfortunately, if a newer version of QuickTime is installed than the one we package, there is an error saying as much. Normally, this would be a minor inconvenience for our users, but if they run a silent install under these circumstances, the installer simply fails.
I could just update the version of QuickTime we package making it more likely that people do not run into this issue (which we will likely do anyway), but that is still a temporary workaround to the real issue. What really needs to happen is that the installer should check if QuickTime is already installed, and if it is, skip attempting to install QuickTime altogether.
I have looked into “Prerequisites” and “Custom Actions” but I have yet to find anything that would let me accomplish this. Am I looking in the right place? If so, what am I missing? If not, is there another way to accomplish this?
In my attempt to use a Prerequisite, I looked for a Registry Key that seemed sensible to use but it seems that QuickTime does not use a Registry Key to simply declare its current version (at least none that I could find). So, despite the fact that it's not remotely ideal, I tried to run the prerequisite depending on whether or not the file QuickTimePlayer.exe existed in [ProgramFiles]QuickTime\. I did not receive any error output, but on a test machine that had no QuickTime installed, the prerequisite did not run.
How do you choose whether to try to install QuickTime?
Prerequisites are designed to detect if something is present, and, if not, install it. Prerequisites detect the presence of something through their conditions, typically looking for a known registry key or file with version information, and comparing against the version they would install. If it's missing or lower, install it; if it's equal or higher, skip it. But you must use the prerequisite editor to tell the prerequisite what to look for.
Can you suggest a tool(if exists) to keep track of all the versions of all the resources i use to develop a project?
i.e. Project:Myproject
IDE:Eclipse
php:5.0.2
iReport Plugin:1.2.1
...
Thanks.
One approach is to use source control: check in the binaries (or installers) for all the tools you use along with your project. When you upgrade a tool, check in the upgraded version, so the source control history includes everything that is needed to build a particular version of your project. If you want to build last year's version of the code, everything you need is then in source control.
(Disk space is cheap, so just keep a copy of everything)
I am doing a concept in linux in which i want to do version rollback for an app installed in linux. Is it possible??
For eg I have an application named X with version 1.1
I get an update. It changes it to version 1.2
I note what all the packages in the app going to be modified.
Then i save them and apply the changes.
Now after sometime due to some problems I want to switch back to version 1.1
If i undo the changes and make the entire solution will the rollback be done?
The easiest and common way in Unix is to install them in separate directories,
eg "/usr/bin/MyApp.1.2.3" and "/usr/bin/MyApp.1.2.4" then create a link to the one to use "/usr/bin/Myapp".
Changing versions is then just a matter of moving the link.
You don't need to invent anything. Just keep the packages you install around. If you want to go back, uninstall the current version and install the previous package again.