I'm trying to install a .deb file... for example:
example.deb.
But the program is already installed in an older version on the Debian minimal server.
So doing dpkg -i example.deb is creating a dialog, if i want to keep the configs...
is there any way to do this none interactive?
You can pipe yes into it:
yes | dpkg -i package.deb
man yes
You seem to be looking for
dpkg --force-confold -i package.deb
to specify that dpkg should prefer the existing, old configuration files in the case when there is a conflict.
More broadly, the proper solution depends on how desperate you are to avoid interactive prompts, and which prompts precisely you want to avoid.
dpkg has a number of options to select a particular behavior for various types of situations. Refer to its man page; scroll to the section on --force-things; one of them is --force-confold, or conversely --force-confnew to always replace any existing configuration file. (Many modern packages have a facility to upgrade any unchanged configurations completely automatically, but manually changed configuration files still require manual updating or merging.)
If you aren't running dpkg directly, apt and friends allow you to pass options to it with
apt install -o Dpkg::Options::="--force-confold" install package
(Yeah, that's a lot of colons. You probably want install -y to avoid interactive prompting by Apt itself, too.)
Setting the environment variable DEBIAN_FRONTEND to the string noninteractive will make Debconf (the configuration management component of Debian) select the default answer for all questions, and disable any prompting.
If the default answers to a package's configuration questions are not suitable, you can preseed Debconf's configuration database with the settings you want. You'll need to install debconf-utils which contains the utility debconf-set-selections. See further its man page and e.g. some sections of https://wiki.debian.org/DebianInstaller/Preseed (though this is rather focused en preseeding the installer, so you can potentially perform an unattended installation of all of Debian).
The problem with
yes | dpkg -i package.deb
is that you can't exactly predict which prompts are going to be shown, depending on the package's and the hosting system's configuration; you might say yes to something you didn't want to, or perhaps tell the system that your domain name or default database user is yes. Debconf was designed to give you very detailed and, for the most part, very safe and robust control over package installation - use that power.
Related
I am going around with no success in installing Transcriber in Ubuntu. Way very difficult :s
I follow all the steps the link above, but no way of passing this part of installing first the tcltk - ./configure --enable-gcc --enable-shared --prefix=/usr/local
make
It doesn't work and gives a bunch of errors. SO I decided to search and do as here, to install tcltk - Install TCL/TK without root
So I tried the code but it didn't work again, starting here sudo ./configure --prefix=/opt/tcltk
It was saying I had no permissions in opt so I found a way to create a tcltk folder, fine, but when I put the sudo it comes:
checking whether to use symlinks for manpages... no
checking whether to compress the manpages... no
checking whether to add a package name suffix for the manpages... no
checking for gcc... no
checking for cc... no
checking for cc... no
checking for cl... no
configure: error: no acceptable C compiler found in $PATH
Seeconfig.log' for more details.
`
I am tired of this guys, if you could please help me to install this I would be very thankful. I understand not that much of ubuntu. Thank you!
You can't compile without a compiler (and linker). They're usually not very happy about being installed in user directories.
sudo apt install build-essential
Alternatively, if you're just wanting to run Tcl code without installing, you can use KitCreator to get your own single-file executable. (Yes, that site will build one for you While-U-Wait. The guy who wrote it isn't big on fancy CSS, even more so than me, but he does make good technology deployments.) There are other options too, but they're either older or less easy to use without being able to install compilers and so on.
I'd like to install programs with conda in one particular conda environment and to be able to use the associated commands from all conda environments.
My goal is to allow students to install Mercurial (plus few Mercurial extensions and related utilities like Meld and TortoiseHg) on any platforms (especially Windows) with one simple command (or few simple commands), and of course without compilation.
Of course the hg command should be available in the terminal from any conda environments (anaconda prompt on Windows). The Mercurial packages cannot be installed in the base environment because Mercurial still works better in Python 2.7 (anyway, it wouldn't be clean).
Now Mercurial and the extensions we need can be installed on all platforms with something like:
conda create -n py27_mercurial -c conda-forge python=2.7 mercurial dulwich ipaddress
conda activate py27_mercurial
pip install hg-evolve hg-git
Working a bit with conda-forge and a conda meta-package, it won't be difficult to do that with one very simple command. Moreover, it should not be difficult to create conda packages for Meld and TortoiseHg.
From this stage, the hg command is available when the environment is activated (and it is very simple to install other Mercurial extensions). To make it available from other environment (and in the base environment), one need to append the path of the directory containing hg to the environment variable PATH or on Unix to create a symbolic link (I don't know Windows enough to know if something similar would work). Both solutions are not straightforward and the commands are not platform independent.
I didn't find a command to do something like this in conda but sometimes conda experts are able to do impressive things! What would be an elegant solution to this issue?
It would also be nice to create icons somewhere (in the Anaconda launcher?) for the graphical applications (Meld and TortoiseHg). Is it possible?
Edit: Conda applications
I discovered that there is a way to specify in the meta.yaml file that a package is an application: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#app-section
It may help to solve the issue.
Edit after a first answer based on a bash function:
Of course, I'm looking for a solution involving very small work (and understanding) for the users and with cross-platform commands.
Note that for Linux and Bash, one can just do:
CONDA_APP_DIR=$HOME/.local/bin/bin-conda-app/
mkdir -p $CONDA_APP_DIR
echo -e "\nexport PATH=\$PATH:$CONDA_APP_DIR\n" >> ~/.bashrc
ln -s $(which hg) $CONDA_APP_DIR/hg
No need to activate/deactivate the environment each time hg is used...
Of course, such solutions dependent of the system and the shell are not satisfactory. It should be possible to do such things with cross-platform conda-like commands (see https://github.com/conda/conda/issues/8556), something like
conda config --add channels conda-forge
conda install conda-app
conda-app install mercurial
Now, I just have to implement conda-app 🙂
One can always create a shell function/alias and shove it in their shell's runtime configuration file. For example, for your use case, I'd add the following in my ~/.bashrc:
hg() {
(conda activate py27_mercurial
command hg "$#"
_hg_exit_code=$?
conda deactivate
exit $_hg_exit_code)
}
Then, regardless of which environment you are in, you always run hg from the environment it was installed in. To make sure that this function is loaded for you shell in a new session, one can always take a look at the output for: type -a hg
I do this one-time-setup for all the tools (some are custom compiled) and have an alias/shell function for each. This way I can happily switch b/w environments without having to worry much.
The solution https://stackoverflow.com/a/55900964/1779806 is buggy for scripts using command hg ... and too inefficient for this case (installation of a command-line application). See https://github.com/conda/conda/issues/8556#issuecomment-488703716
I created a tiny Python package conda-app (https://pypi.org/project/conda-app/) to improve this situation.
This should now works on Unix systems (with Bash and Fish):
conda activate base
conda config --add channels conda-forge
pip install conda-app
conda-app install mercurial
It should not be difficult to improve conda-app to also support Windows.
For the time being, Windows users can install Mercurial and important extensions by installing TortoiseHG.
I'm working on a mysql installation script for our system, to be part of an automated deployment system. Looking through previous installations, it seems like we might have been loading redundant packages, some via apt some via pip. Looking at Ansible roles for mysql also reveals slightly differing default package lists (e.g. this and this). So I thought I would look up what these packages actually do---only to find that I couldn't find anything informative.
The definitive list, presumably, is this one from MySQL. However I find descriptions like "MySQL database common files" not very helpful. Common to what?
So my general question: is there a better summary of what the different packages do? And if the answer to that is no, then at least can anybody tell me when/why I would want to explicitly install these packages (which were included in my legacy scripts):
mysql-common
libmysqlclient20
libmysqlclient-dev
and in the case of the last two, why I would install one or both of those, vs simply installing mysql-client (the "meta" client installer)?
I got two serveurs. ClientServ and DevServ. The client serveur is on Debian 7 with Mysql 5.5.49-0+deb7u1. My goal is to have the same package in my DevServ.
Unfortunaly, I tried to apt-get install I only got "5.5.55-0+deb7u1". I checked the repo actually there isn't any 5.5.49 package in wheezy...
I tried everything.
Using mysql's .deb, it gives only mysql with the correct version but not the other composents (mysql-server etc).
I saw that in Jessie repo there is a "mysql-server-5.5 5.5.49-0+deb8u1"
Is it possible to use it ?
Please help me... :)
Thank you very much in advance,
Good day
There should be no issues simply downloading all the *.deb packages and installing them for the relevant version of the mysql server. Note that you'd also need to grab the *.deb files for any mysql modules you need at the same time.
Then you just install them directly with dpkg, after first having purged all the installed mysql packages ( apt-get remove --purge mysql* ). Personally however I would not do this, I have never found any significant issue using varying mysql server versions between live and dev machines, and particularly if both are the same version, 5.5, I don't see why you'd experience any significant issues, but if it's actually and critically mandatory to run precisely the same versions, then directly installing the deb files should work fine.
Just make sure to download them and store all the mysql files you'd ever potentially need in a directory somewhere so you have them to install in case the versions you needed go away, or in case you realized you'd forgotten a module or something.
If this is only a dev system, I think personally I'd just install the debs directly to avoid versions changing.
But unless you are absolutely certain some key difference exists between those two debian versions, which probably is not the case, it's probably just some security update or something that has no impact on how mysql server processes sql, I'd just use what is in jesse, and not worry about it.
Sample:
http://mirrors.kernel.org/debian/pool/main/m/mysql-5.5/
There you see versions 47 and 55, for example, of the server, and you'd also grab the 'core' package as well to match. Tnen you'd look for any other modules you might need here:
http://mirrors.kernel.org/debian/pool/main/
keeping in mind that with dpkg, you have to install the dependency first, then the next package, or both together in some cases. However, what I would do first, not last, in your case, is to make sure there actually is a functional difference between the different 5.5 versions before dealing with the potential headaches involved in trying to maintain a server using dpkg deb package installs.
Here's, for example, a list of mysql packages you might need. Note that I just grabbed this off a dev box, this is not intended to be an authoritative list, just an example, but it does show that mysql is used in many different places on a system, and you might run into issues trying to downgrade manually, which is why I'd in general avoid trying this method (for illustration purposes I changed 5.6 to 5.5). The key is to take the absolute minimum package list to download manually the deb files for.
dpkg -l | grep mysql | awk '{print $2}'
libaprutil1-dbd-mysql:i386
libdbd-mysql-perl
libmysqlclient15off
libmysqlclient16
libmysqlclient18:i386
libqt4-sql-mysql:i386
libqt5sql5-mysql:i386
mysql-client-5.5
mysql-client-core-5.5
mysql-common
mysql-server-5.5
mysql-server-core-5.5
php5-mysql
You'd just take the existing mysql install that is working and run that command to see the packages you need to download. As you can see, it's a pain, which is why I'd generally avoid trying to do a development install in this way, I've never hit any sql issues, or return issues using vastly differing mysql versions, so unless your sql queries are using things only found in the specific version, which is very unlikely, you are unlikely to gain much. But this is how you do it in case future searchers land here.
Note that most dev boxes are probably running desktops, and have more mysql dependencies than just the mysql server stuff for web development, and that can lead to issues.
I want to know how to build grub 2 bootloader from it's source in ubuntu and test it with qemu emulator.
I would also like to change the default background image of grub2 bootloader in the new build?
Is this possible? If yes, how ?
Of course you can.
As shown on the GRUB website, the grub source code is available via git from git.savannah.gnu.org.
Then it is theoretically just a question of
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
However, depending on your platform, grub's default target platform may or may not be what you want. So you will need to decide which firmware platform you want to use in QEMU, which depending on your architecture can be something like
(pc) BIOS
coreboot
(U)EFI
ieee1275 (open firmware)
u-boot
Your mentioning of Ubuntu matches at least 3 possible options from the above, but I'm going to be boring and assume you mean x86_64/amd64. Since you will be running GRUB under QEMU, it does not really matter which of the two likely platforms ("pc" or "efi") your physical computer is running. So let's live a little and go for the (U)EFI variant.
You will need some prerequisites installed before configuring and building, so
$ sudo apt-get install build-essential autoconf automake
$ sudo apt-get build-dep grub-efi-amd64
So a practical build may look a bit like this:
$ # Next command is optionnal (languages):
$ ./linguas.sh
$ ./autogen.sh
$ # Next parameters are optionnal:
$ ./configure --prefix=$HOME/local --platform=efi
$ make
$ # Next command is optionnal:
$ make check
$ make install
The easiest way to get a functioning GRUB image is probably with the grub-mkstandalone command:
$ $HOME/local/bin/grub-mkstandalone -O x86_64-efi -o mygrub.efi
Note: To install grub on /dev/sda disk (instead of QEMU), use:
$ sudo grub-install /dev/sda
Note: If you don't see GRUB menu when booting, check this question. It involves pressing Shift when booting or editing /etc/default/grub to comment GRUB_HIDDEN_TIMEOUT.
Then you need some kind of UEFI image to run under your QEMU. The default choice for x86 is called OVMF and is part of Tianocore EDK2 - the de facto open source implementation of UEFI. Due to legal technicalities with regards to redistribution of the FAT filesystem driver, many Linux distributions (including Ubuntu) do not include a pre-built one. But have no fear, it is pretty straightforward to build one yourself.
However, I am not going to take this answer further off-topic than I already have, so all I am going to say is have a read through the OVMF README and look through one or two only slightly outdated blog posts about it.