Linux软件包的管理--源码管理

任何管理工具都有自己最适用的场景,像软件包的管理,在CentOS系列中,有了RPM包管理器,但是它自动不能解决包的管理器,所以就出现了yum管理器,但是,他却不能符合我们实际要求(定制功能),所以就出现了源码管理。也许,有些时候源代码也不能满足我们的要求,我就可能要自己基于源码进行二次开发。这里,我们讲解源码管理。

一、源码安装步骤

源码编译的前提,得有像gcc,make等编译工具。一般情况下在“Development tools”里面都提供了这些编译工具。

源码安装步骤其实没有特定的步骤,原因是不同的源码制作者的制作方式的不同导致了我们使用的安装步骤和选型都有所差异。但一般情况下,制作者会遵循一些特定的规则。所以,一般情况下,源码编译是以下几步。

以安装ngnix服务为例:

# tar xf 软件包的压缩文件

[[email protected] ~]# tar xf nginx-1.4.7.tar.gz

# cd 解压后的软件目录

[[email protected] ~]# cd nginx-1.4.7
[[email protected] nginx-1.4.7]# pwd
/root/nginx-1.4.7

# ./configure   还需通过许多选项指定编译特性

[[email protected] nginx-1.4.7]# ./configure --prefix=/usr/local/nginx
checking for OS
 + Linux 2.6.32-358.el6.x86_64 x86_64
checking for C compiler ... found
 + using GNU C compiler
 + gcc version: 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) 
checking for gcc -pipe switch ... found
checking for gcc builtin atomic operations ... found

##########中间省去好多checking############################

checking for zlib library ... found
creating objs/Makefile
Configuration summary
  + using system PCRE library
  + OpenSSL library is not used
  + using builtin md5 code
  + sha1 library is not found
  + using system zlib library
  
  # 如果配置正确,此时会显示个文件的路径
  nginx path prefix: "/usr/local/nginx"
  nginx binary file: "/usr/local/nginx/sbin/nginx"
  nginx configuration prefix: "/usr/local/nginx/conf"
  nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
  nginx pid file: "/usr/local/nginx/logs/nginx.pid"
  nginx error log file: "/usr/local/nginx/logs/error.log"
  nginx http access log file: "/usr/local/nginx/logs/access.log"
  nginx http client request body temporary files: "client_body_temp"
  nginx http proxy temporary files: "proxy_temp"
  nginx http fastcgi temporary files: "fastcgi_temp"
  nginx http uwsgi temporary files: "uwsgi_temp"
  nginx http scgi temporary files: "scgi_temp"

此时会在当前目录中生成一个Makefile的文件,里面内容如下:

# 里面定义了执行不同动作所执行的语句,每个软件的形式可能会各有不同

default:	build

clean:
	rm -rf Makefile objs

build:
	$(MAKE) -f objs/Makefile
	$(MAKE) -f objs/Makefile manpage

install:
	$(MAKE) -f objs/Makefile install

upgrade:
	/usr/local/nginx/sbin/nginx -t

	kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
	sleep 1
	test -f /usr/local/nginx/logs/nginx.pid.oldbin

	kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

# make

# 执行编译操作,有过Linux C编程经验的来说,此步骤是利用gcc生成链接文件

# make install

# 此步骤是真正的安装操作,其实就是复制(或创建)对应的文件到指定路径下。

执行这2步,软件就算安装完成。

./configure脚本的使用:

1、获取帮助

./configure --help

2、较通用的一些选项

安装路径相关:

--prefix=/path/to/somewhere: 指定安装路径

--sysconfdir=/path/to/somewhere: 指定配置文件安装路径

指定启用/禁用的特性

--enable-FEATURE: 例如--enable-fpm

--disable-FEATURE: 例如--disable-socket

指定所依赖的功能、程序或文件

--with-FUNCTION[=/path/to/somewhere]

--without-FUNCTION

二、安装后的配置

1、如果只是程序的的运行,不做为其他软件开发的依赖环境

1)我们可以再全局下使用软件的相关功能

当然实现这样的办法有多种,例如:将这些命令作为链接文件,链接至PATH变量中的某一路径;或者将这些命令拷贝到PATH变量中的某一路径;或者修改环境变量的值,将命令的路径添加进去。

我这里演示的方法是:

在 /etc/profile.d/下建一个于软件名相同的脚本,例如:nginx.sh。添加如下一行内容

export PATH=$PATH:/path/to/somewhere # 例如:export PATH=$PATH:/usr/local/nginx/sbin/
# 完成这步骤后,重新登录就可以正常使用

2)导出手册页:

编辑/etc/man.config配置文件,添加一项MANPATH,路径为新安装的程序的man目录;

当然,我们也可以通过man -M 指定帮助文档路径查看。

3)如果我们想使用像其他RPM包软件的启动方式,此时我们就要自己写相关格式的脚本放到/etc/init.d目录下统一管理。

2、如果作为程序开发:即其它应用程序依赖此程序的开发环境,或针对此程序做二次开发

1)导出库文件

第一步:指定让系统搜索定制的路径

编辑/etc/ld.so.conf.d/APPNAME.conf

# 例如,在/etc/ld.so.conf.d/目录下建一个nginx.conf(只是举例,ngnix不一定有库文件)
# 一行一个库文件路径
/usr/local/ngnix/lib

第二步:触发系统重新搜索所有的库文件并生成缓存,因为系统在启动时已经通过 /etc/ld.so.cache 这个文件缓存了库文件

# ldconfig

-v 显示过程

2)导出头文件

导出方式:创建链接进行

# 假设: ngnix的头文件是/usr/local/nginx/include
ln -sv /usr/local/nginx/include /usr/include/nginx

总结:本文主要介绍了源码如何安装软件包。

时间: 2024-10-12 23:30:28

Linux软件包的管理--源码管理的相关文章

jenkins使用Git为源码管理(windows master && linux slave)

作为一个不太经常总结的人,工作以来碰到过太多问题!往往解决之后没有有效记录,导致再次碰到需要重新查资料解决.现在改变下习惯,努力搞的了技术. 公司最近提倡开源(以前啥都机密,即使开源也没改变多少),代码从SVN迁移至Git管理,这样导致原来记录项目日志的wiki持续集成job需要重新配置.之前的设置为:每分钟检查SVN变化,有变化就执行编译发布.改为Git后,碰到坑坑洼洼,一并列在下面. jenkins的Git插件安装 git plugin,git client plugin,github pl

jenkins持续集成源码管理选项为None,构建失败找不到git.exe解决办法

我的jenkins版本为Jenkins ver. 2.19.1 1.源码管理选项只有None的解决办法: 在插件管理中心,搜索对应的源码管理插件这里以git为例,搜索git plugin点击右下角的安装方式(在线安装需要连接VPN你懂的),如下图 重启后即可看到git按钮: 2.jenkins持续集成时,点击构建失败无法找到git.exe解决办法如下图: 控制台输出提示构建失败git.exe rev-parse --is-inside-work-tree # timeout=10:原因是没有找到

jenkins配置源码管理git

一.首先安装上来jenkins 二.下载安装jenkins的git插件:Git plugin 三.新建一个jenkins项目,选择构建一个自由风格的软件项目: 源码管理选择git,Repository URL填写git 仓库的地址: 我的地址为:[email protected]:/home/repo/test.git    格式为:[用户名]+[@]+[git服务器地址]+[:]+[git仓库地址] Credentials有两种方式,一种是配置以git用户名和密码,另外一种是使用密钥对的方式

[转] 使用SVN进行源码管理

原文地址:gyzhao's, 使用SVN进行源码管理(下) 1.SVN服务端配置 在团队开发中,源码版本控制工具是最重要的工具之一,用来追踪.维护源码,并为项目创建分支,统一对源码进行管理并协同开发.SVN服务器端配 置的主要步骤有:创建版本库.创建用户.用户权限设置.下面是使用VisualSVN Server对Subversion进行的这些操作. 1.1 创建版本库 运行VisualSVN Server,选择"Repositories",点击鼠标右键,选择"Create N

源码管理的新15条建议

作者:张克强    作者微博:张克强-敏捷307 建议之1:使用好的配置管理工具,也称为版本号控制工具(Version Control), 比方Git,SVN. 请彻底抛弃 VSS.假设是新採用配置管理工具,CVS已经不再是选项. 配置管理工具与版本号控制工具能够理解为指的是同样工具. 建议之2:抛弃古老的配置管理三库做法,常说的三库是指开发库(动态库).受控库和产品库(静态库).做法是开发库->受控库->产品库. 在当年没有强大版本号控制工具的"古代",三库做法是不得不的

试用web版源码管理软件SCM-Manager

背景 一直使用 “VisualSvn Server” 作为源码管理工具,使用一段时间之后,使用场景遇到以下问题 添加用户必需登录到服务器. 一台服务器,只能安装一个 “VisualSvn Server” 服务,各小组若共用服务器,用户.svn库不能很好隔离 解决方式 SCM-Manager 支持svn.git.Mercurial 下载 从地址 https://www.scm-manager.org/download/ 下载合适的软件版本 tomcat寄宿,使用SCM-WebApp 1.46(目前

源码管理十诫

英文原文:The 10 commandments of good source control management 若是还有能够毫无偏见地涉及各个编程语言.比源码管理软件更必要的工具.我倒是非常想见识一下.源码管理软件是我们工作的必备工具.是很多开发团队的血液.那为什么我们都会对它有所误解呢?为什么都非常难理解版本号控制系统的核心价值和基本原理呢? 我总结出 10 条惯例--假设你愿意也能够用"戒律"--意味着必须服从它并且从一開始非常难去理解. 它们与全部类型编程语言的版本号控制软

使用GIT进行源码管理 —— 在VisualStudio中使用GIT

GIT作为源码管理的方式现在是越来越流行了,在VisualStudio 2012中,就通过插件的现实对GIT进行了官方支持,并且这个插件在VS2013中已经转正.本文在这里简单的介绍一下如何在Visual Studio中使用GIT进行源码管理. PS: 由于篇幅所限,本文并没有对相关基础知识进行介绍,在读取本文前,假定你已经对GIT有一定的了解,并且对VisualStudio的团队管理器比较熟悉,后续有时间的话再进行相关知识的介绍. 将项目添加到GIT源码管理 将项目添加到GIT源码管理和通过T

谈谈源码管理那点事儿(一)——源码管理十诫(转)

引言: 若是还有能够毫无偏见地涉及各个编程语言.比源码管理软件更必要的工具.我倒是非常想见识一下. 源码管理软件是我们工作的必备工具,是很多开发团队的血液. 那为什么我们都会对它有所误解呢?为什么都非常难理解版本号控制系统的核心价值和基本原理呢? 原文作者总结出10条惯例(假设你愿意也能够用"戒律")意味着必须服从它,并且一開始非常难理解. 它们与全部类型编程语言的版本号控制软件都有关联.在这里我选取了Subversion和.NET的几个样例,只是它们也广泛地适用于其它的一些技术. 英