Server OS is Fedora 24. 64bit.
I want to install Git 2.6.6.
So download source code and installed.
This server is offline. So i don't use 'yum'.
./configure --prefix=/usr/local/git-2.6.6
make prefix=/usr/local/git-2.6.6 all
this is error message.
Can't locate ExtUtils/MakeMaker.pm in #INC (you may need to install the ExtUtils::MakeMaker module) (#INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at Makefile.PL line 3.
So I install ExUtils::MakeMaker.
First I download rpm file(https://fedora.pkgs.org/24/fedora-x86_64/perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch.rpm.html)
And install rpm file
[root#swcm 다운로드]# rpm -ivh perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch.rpm
오류: Failed dependencies:
perl(ExtUtils::Install) >= 1.52 is needed by perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch
perl(ExtUtils::Installed) is needed by perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch
perl(ExtUtils::Packlist) is needed by perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch
perl-ExtUtils-ParseXS is needed by perl-ExtUtils-MakeMaker-7.10-4.fc24.noarch
[root#swcm 다운로드]# rpm -ivh perl-ExtUtils-Install-1.54-3.noarch.rpm
경고: perl-ExtUtils-Install-1.54-3.noarch.rpm: Header V3 DSA/SHA1 Signature, key ID 4026433f: NOKEY
오류: Failed dependencies:
perl(ExtUtils::MakeMaker) is needed by perl-ExtUtils-Install-1:1.54-3.noarch
perl(VMS::Filespec) is needed by perl-ExtUtils-Install-1:1.54-3.noarch
perl-ExtUtils-MakeMaker need to perl-ExtUtils-Install.
perl-ExtUtils-Install need to perl-ExtUtils-MakeMaker.
I don't know. What should I do?
Firstly, do you realise that Fedora 24 support ended last week? You are now using an unsupported operating system. I recommend upgrading to Fedora 25 or 26 as soon as possible.
Secondly, the version of git that is available for Fedora 24 is 2.7.4. You can download the RPM for this version from here. If you specifically need an older version, then perhaps you could explain why you think that (it's rarely true in my experience).
Thirdly, I think you're running up against Fedora's deliberately broken Perl installation. What you really want to do is to install the perl-core RPM (but that has dozens of dependencies that you will need to download).
To solve your current circular dependency problem, try installing both RPMs at the same time.
$ sudp rpm -ivh perl-ExtUtils-MakeMaker-*.rpm perl-ExtUtils-Install-*.rpm
But your life is going to get a lot easier if you can connect this machine to the internet - even temporarily.
you can try carton.
write a cpanfile
carton install on one server with internet
carton bundle
then scp those .tar.gz or whatever to the server do not have internet
carton install --cached (or cpanm the .tar.gz directly)
once done, move those files under local to the system dir.
https://metacpan.org/pod/Carton
another way is that you can install all those modules with the server has internet (same OS), then scp or rsync the installed files)
Thanks
Related
A few days ago I had a few problems while installing trying to install lapis on my new installation of linux mint. The main problem was that I wanted to have lua 5.3 as the main lua interpreter on my system, but lapis only works with lua 5.1.
This is how I ended up installing it
Note: Instructions for normal installation process, with aditional lua 5.3 being optional
Prerequisites
First of all install all the prerequisites with apt-get install libreadline-dev libncurses5-dev libpcre3-dev libssl-dev perl make build-essential*. This is all you should need to install lua, luarocks and openresty.
* copied from openresty website
Lua Interpreter(s)
Next, go to https://www.lua.org/versions.html and download the latest version of lua5.1 (wget https://www.lua.org/ftp/lua-5.1.5.tar.gz). Then extract the downloaded file tar -xf lua-5.1.5.tar.gz and optionally rename the directory mv lua-5.1.5 lua51.
Now you can simply build and install lua by moving to the directory cd lua51 and running make make linux and sudo make install
Aditionally, you might want to have lua5.3 installed on your system as the main lua interpreter. Luarocks doesn't seem to particularly like this kind of setup though, so I recommend the following:
First download and extract (and optionally rename) both lua5.1 and lua 5.3; go to the lua 5.1 directory and open Makefile in a text editor; Edit lines 12-15 to install lua in another directory. For me it worked to just add /lua51 to INSTALL_TOP (line 12). Next go to line 44 and change the names of the binaries (I chose lua51 and luac51), optionally do the same with the man pages (this requires also changing them in the doc subdirectory).
The next step is to go to the src/ directory and edit the makefile there as well: in lines 32 and 35 change the names as you did in the previous makefile (lua51 and luac51 in my case).
After this you can just make linux and sudo make install as described above.
Luarocks
Now you need to install luarocks on your system. Start by downloading the latest release of luarocks (http://keplerproject.github.io/luarocks/releases/) and extract it. Again, you can rename it to luarocks/ reduce typing. cd to the directory you just extracted and run ./condigure.
If you changed the lua installation path, you will have give some parameters to the configure script:
For lua 5.1 ./configure --lua-version=5.1 --with-lua=/usr/local/lua51 --lua-suffix=51 is how I had to do it (--lua-suffix is what I added to lua and luac and --with-lua tells it where the bin, lib, etc. subdirectories are; only relevant if you changed INSTALL_TOP in the makefile)
Optionally you can now proceed to (download, ) build and install lua 5.3 with its standard configuration. After that you can even go back to the luarocks directory and repeat ./configure, make build and make install and it should automatically install itself with lua 5.3 and leave the installation for lua5.1 intact**.
** the luarocks executable is actually just a symlink to luarocks-VERSION (where VERSION can be 5.1, 5.3, etc.) in the same directory. Each time you install luarocks this link is overwritten to point to the latest installation, but the other executables are still there.
OpenResty
The next step is to install OpenResty: open http://openresty.org/en/installation.html and check the prerequisite section. It should say the same as at the beginning of this answer. If not, install any missing package now. You can also just follow the installation instructions there, but I will be repeating it anyway; go to http://openresty.org/en/download.html and download the latest version. Extract the downloaded archives (and rename the new directory to simply openresty). cd to the new directory and run ./configure --with-pcre-jit --with-ipv6 (this might take a while), make (this might take an even longer while) and sudo make install.
At this point everything except lapis itself should be set up and working.
Lapis
To install lapis, type sudo lurocks install lapis (user luarocks-5.1** instead if you have installed more than one version of it).
Congratulations! If you got no errors, you should now have lapis installed and ready to use :)
** see section Luarocks.
I want to host an apt-get repository.
How do I package my application, and how do I host it in a repository for use?
The application relies on Java, MySQL, upstart and is configured to run on boot as an upstart service.
The answer should also include, how to host the package on a repository.
Ref:
How do I package a Java program for Ubuntu?
How do I package Mono applications for Debian/Ubuntu
Packaging for Ubuntu - Web Application
Good question, maybe a personal ppa is what you are looking for. After you finish you will have to do a $ sudo add-apt-repository ppa:myApp/ppa. Then you can apt-get install it.
To package your application you will need to do this in your apps directory
myappFolder$ dh_make -p myApp_1.0 --createorig
To create a original tar of your app. This will also create a Debian folder with a control file, a rules file, changelog... Change the values in these files to fit how your package should be. Specifically the control file. You will have a Depends: field where you can write in packages your application relies on such as Java and MySQL, make sure to have the same names as Ubuntu repository for these things.
goodLink https://www.debian.org/doc/manuals/maint-guide/dreq.en.html
Check out chapter 5 the install file and then building the package in chapter 6. I use dpkg-buildpackage usually. debuild -us -uc is good too look up too.
Then create an account on Ubuntu launchpad.
https://login.launchpad.net/+new_account
Sign the Ubuntu code of conduct:
https://launchpad.net/codeofconduct (take away the extra h, no reputation for more links)
Activate a PPA:
https://launchpad.net/people/+me/ (extra h)
Then follow this guide to upload the package to your ppa:
https://help.launchpad.net/Packaging/PPA/Uploading (extra h)
I got these links from a great answer on ask.ubuntu. It's also got a more lengthy answer on creating a deb package.
https://askubuntu.com/questions/71510/how-do-i-create-a-ppa
I'm trying to install dkms onto machines that have no make or gcc.
I plan to push only binaries to those target machines.
On my build machine I plan to use dkms to build dkms-enabled modules and then use dkms mktarball ... --binaries-only to create tarballs for distribution.
I want to push those tarballs to target machines, and on those machines I
want to use dkms ldtarball, and so the target machines do need dkms,
but they don't need gcc (or make).
Build (host) and target machines run the same Ubuntu
apt-get install dkms on the target automatically brings in gcc
Downloading the dkms.deb (apt-get download dkms)and installing it with dpkg --install --ignore-depends=gcc ... dkms.deb
does work, but leaves the dependency unresolved so that any future apt-get (installing some other package for instance) fails.
I can try to use the equiv package to create dummy installations of gcc and make, but this seems like an awful hack I'd prefer to avoid. Also it could create problems if I ever want to actually install
gcc on the target in the future.
There's a note about this in the dkms README (section 3), but no guidance on how to accomplish it.
"If you choose not to load module source on your system or if you choose not to load a
compiler ... DKMS can still be used to install modules.".
(sorry if the tags are misleading ... there's no tag available for dkms)
Create a local dummy package which pretends to install gcc and any other deps you want to keep off your system. The equivs package can be used for this, but it's simple enough to do by hand as well.
Many thanks to Darik Horn for an excellent (offline) answer.
He suggested using /etc/apt/preferences.d to pin the unwanted packages. That solution looks promising and I will explore further (and post results here if possible).
I was able to find another solution Ubuntu Forums and at Superuser which looks promising.
The steps which the script performs can be done manually and are basically this:
mkdir
dpkg-deb -x dkms...deb
dpkg-deb --control dkms...deb /DEBIAN
Edit the /DEBIAN/control file Depends line
dpkg -b dkms-modified-...deb
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.
I want to install multiple versions of a package (say libX) from src. The package (libX) uses Autotools to build, so follows the ./configure , make, make install convention. The one installed by default goes to /usr/local/bin and /usr/local/lib and I want to install another version of this in /home/user/libX .
The other problem is that libX is a dependency for another package (say libY) which also uses autotools. How to I make libY point to the version installed in /home/user/libX ? There could be also a possibility that its a system package like ffmpeg and I want to use the latest svn version for my src code and hence build it from src. What do i do in that case ? What is the best practice in this case so that I do not break the system libraries?
I'm using Ubuntu 10.04 and Opensuse 10.3.
You can usually pass the --prefix option to configure to tell it to install the library in a different place. So for a personal version, you can usually run it as:
./configure --prefix=$HOME/usr/libX
and it will install in $HOME/usr/libX/bin, $HOME/usr/libX/lib, $HOME/usr/libX/etc and so on.
If you are building libY from source, the configure script usually uses the pkg-config tool to find out where a package is stored. libX should have included a .pc file in the directory $HOME/usr/libX/lib/pkgconfig which tells configure where to look for headers and library files. You will need to tell the pkg-config tool to look in your directory first.
This is done by setting the PKG_CONFIG_PATH to include your directory first.
When configuring libY, try
PKG_CONFIG_PATH=$HOME/usr/libX/lib/pkgconfig:/usr/local/lib/pkgconfig ./configure
man pkg-config should give details.