关于 Linux 下面的 包管理器的 疑惑 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
huyangq
V2EX    Linux

关于 Linux 下面的 包管理器的 疑惑

  •  
  •   huyangq 2022-05-11 15:40:27 +08:00 4786 次点击
    这是一个创建于 1300 天前的主题,其中的信息可能已经有所发展或是发生改变。

    linux 的包管理器很强大 下载软件十分的方便 但是下载的软件各个目录 好像是分散在 各个目录中的,比如下载了 redis 启动程序 好像在 /usr/bin 中 数据好像在 /usr/local/redis-3.2.0/data 为啥 要这种设计呢? 直接在一个固定的目录下面不行吗?

    28 条回复    2022-05-12 07:21:29 +08:00
    kujio
        1
    kujio  
       2022-05-11 15:45:07 +08:00
    bin 里存放可执行文件
    local 存放缓存数据
    很合理啊。
    richangfan
        2
    richangfan  
       2022-05-11 15:48:45 +08:00
    约定俗成,`/usr/bin`放系统软件,`/usr/local/bin`放用户软件
    seers
        3
    seers  
       2022-05-11 15:51:20 +08:00 via Android
    linux fhs
    ration
        4
    ration  
       2022-05-11 15:52:18 +08:00 via Android
    你放在一个目录,那你只能到目录里启动程序了。如同 windows 下也要配置环境变量,路径之类的
    iamzuoxinyu
        5
    iamzuoxinyu  
       2022-05-11 15:53:39 +08:00
    Unix 规范。现在有了 snap/flatpack 之类的容器化的打包方式,可以将一个应用的资源全部放在一块。
    masterclock
        6
    masterclock  
       2022-05-11 15:54:08 +08:00
    这东西大概是 1969 年发明的,甚至早于创世纪,很难修改了
    SaltyKitkat
        7
    SaltyKitkat  
       2022-05-11 16:07:13 +08:00
    根据 fhs 约定来如此安排的
    好处是从某种角度的方便
    头文件在 /usr/include
    可执行文件在 /bin, /sbin, /usr/bin, /usr/sbin
    动态链接库在 /lib, /usr/lib
    可以免得安装一个库之后,其他依赖这个库的软件发生“找不到 libxxx.so”错误,还需要手动配置各种环境变量啥的

    坏处就是像你说的,一个软件包安装之后就变成“散装”的了,各个文件散布在不同地方,包管理器需要记录每个软件包和它的文件的对应关系才能工作

    至于你的想法“直接在一个固定的目录下面不行吗?”
    当然行啊,只不过不符合一直以来比较主流的约定罢了
    比如 NixOS 这个发行版,就可以认为是把每个软件都安装在 /nix/store 路径下面一个“固定的目录”里面(当然实际情况要比这复杂得多)
    adoal
        8
    adoal  
       2022-05-11 16:09:10 +08:00   1
    我见过很多不做运维的纯开发人员都对 FHS 困惑和反感

    https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
    adoal
        9
    adoal  
       2022-05-11 16:17:58 +08:00   2
    把文件按作用分类到不同目录,而不是按业务领域,有些可能的好处。因为通常文件在文件系统里的权限、性能、易变性是按作用而不是按业务领域来划分的。

    比如[/usr]/[bin|sbin]下的可执行程序、[/usr]/lib 下的动态链接库,/usr/share 下的静态数据,通常不需要普通用户有写入权限;/var/lib 下的数据库、/var/log 下的日志通常需要各自的 uid 有写入权限;/etc 下的配置通常在程序和数据做小版本升级时不需要改动,但管理员可能要单独修改;/run 下的 pid 、socket 最好在系统重启后就没了,以免判断错误。等等。
    再比如,在资源受限的环境(比如路由器),可执行程序和不可变数据可以做成只读的压缩文件系统,启动后部分解到内存或者按需解开;配置文件需要改变后持久化到闪存;日志通常不需要持久保留。

    按 FHS 划分就很容易为不同业务功能但相同作用的文件设置统一的存储策略。而按业务领域划分,从这个角度看反而是散乱的。
    adoal
        10
    adoal  
       2022-05-11 16:20:55 +08:00
    RPM 系和 DEB 系主流发行版里打包好的包都是按 FHS 来。

    而单位自用业务系统里的业务功能部分,不论是搞外包的传统行业的信息化还是自养开发团队的互联网,普遍倾向于按业务领域划分,everything-under-business-prefix……
    huyangq
        11
    huyangq  
    OP
       2022-05-11 16:38:38 +08:00
    哦哦 那问题来了 假如我在启动的时候 需要改一下配置文件 比如我改一下端口号 那还得找 那多麻烦啊
    huyangq
        12
    huyangq  
    OP
       2022-05-11 16:39:49 +08:00
    @adoal 鱼跟熊掌不可兼得 有点理解了
    libook
        13
    libook  
       2022-05-11 16:47:06 +08:00
    FHS 是个通用标准,大家尽量按照统一标准来做。

    放独立目录也不是不可以,比如自己编译的一些软件可能会放在 opt 目录下,但你就得自己搞定环境变量啥的,不像统一放在 bin 、lib 目录下有统一的环境变量可以用。
    yohole
        14
    yohole  
       2022-05-11 17:06:09 +08:00
    不懂就问:macos 现在安装的软件是不是就放在一个文件中,卸载其实就是直接把这个文件删除掉?
    iamzuoxinyu
        15
    iamzuoxinyu  
       2022-05-11 17:14:58 +08:00
    @yohole 有一些其实就是个 xxx.app 文件夹,运行的依赖都在里面,常见于纯 GUI app 。cli app ,其实也大体遵从这个规范的。
    libook
        16
    libook  
       2022-05-11 17:19:52 +08:00
    @huyangq #11 配置文件通常统一放在 etc 下面,很好找的,惯例也是只动这个目录下的配置文件,其他目录的作为默认配置被覆盖。
    libook
        17
    libook  
       2022-05-11 17:23:48 +08:00
    @yohole #14 macos 安装软件分两种,一种是跑在苹果自己的应用框架下的应用程序,统一放在 Applications 里;另一种是 Unix 程序,也会放在 FHS 结构里。
    andyhuzhill
        18
    andyhuzhill  
       2022-05-11 17:24:39 +08:00
    @huyangq 都按照 FHS 标准的话 配置文件都在 /etc 目录下了 很好找啊
    libook
        19
    libook  
       2022-05-11 17:25:12 +08:00
    @yohole #14 其实 Linux 也有类似 macos 的方案,比如 snap 应用,可以了解一下。
    SenLief
        20
    SenLief  
       2022-05-11 17:39:32 +08:00
    linux 也有 snap 这种放在一起的。FHS 的标准好处是,你想要修改配置文件理论应该在 /etc/app/下面。
    fengyj
        21
    fengyj  
       2022-05-11 17:45:36 +08:00
    这些都还好吧,因为 FHS 标准如此。
    但是 FHS 标准有些时候挺抓狂的,尤其是 opt 的文件夹,就没几个开发喜欢放那
    westoy
        22
    westoy  
       2022-05-11 17:50:49 +08:00
    你这个会把数据放 /usr/local/redis-3.2.0/data 下面的不像什么正经的包管理啊

    /usr/local 一般官方的包管理不会去碰的, 数据是放 /var/lib/XXXX 下面的
    Huelse
        23
    Huelse  
       2022-05-11 17:51:05 +08:00
    如果不遵守约定或不知道应该怎么放,就放在自己用户目录下吧 ~/
    Buges
        24
    Buges  
       2022-05-11 18:03:03 +08:00 via Android
    因为这种目录结构能集成。比如一个应用的本体可执行文件可以直接在终端运行,那就放到 /usr/bin 里。如果给其他程序提供库,那就放到 /usr/lib 里。如果要添加文件关联,直接放到 /usr/share/applications 里。配置文件统一放在 /etc ,数据在 /var/lib/appname 等等。比 Windows 注册表那样添加一堆莫名其妙的东西卸载了还删不干净好吧。
    lolizeppelin
        25
    lolizeppelin  
       2022-05-11 18:16:00 +08:00
    window 闭源都不共享内容,自然都是自己东西全放自己文件夹完事也不需要什么规范,也就是大家最喜欢的绿色模式

    linux 是个开源共享的系统,共享意思是你可以用我东西我也可以用你东西,为了方便共享大家有统一规范

    非共享的情况软件自己管好自己一亩三分地就可以,没有依赖也不需要依赖管理,因为别人和你没关系
    共享就要遵守统一规则否则依赖混乱,你自己变更还要考虑到别人的兼容
    whenov
        26
    whenov  
       2022-05-11 21:05:32 +08:00
    可以关注下 GoboLinux ,根目录结构为:
    Depot Mount System Files Programs Users
    baobao1270
        27
    baobao1270  
       2022-05-12 02:24:48 +08:00
    题主说的不对,要么是 /usr/bin 放程序、/var 放数据;要么放 /usr/local/bin 、/usr/local/var
    如果用包管理器,几乎不会用到 /usr/local ,如果遇到了说明打包者没有打包好(编译时设置了错误的 prefix 选项)

    这个标准叫做 FHS 。其实 FHS 这个东西也有点过时了,现在很多发行版都在作 USR Merge (只保留 /usr /etc /var ,/bin 、/sbin 、/lib 都是软连接)

    FHS 确实有很多优点,但是在某些场景也有一些不太令人满意的地方。我感觉最好是单开一个 /app 目录,然后设置 /app/something/bin 、/app/something/lib 、/app/something/etc ,然后软连接到 /usr/bin 、/usr/lib/something 、/etc/something 。
    codehz
        28
    codehz  
       2022-05-12 07:21:29 +08:00
    主要的问题是为了使用共享库,而为了使用共享库,必然就得有公共路径,这样一来,单独给程序放独立文件夹的意义就少很多了 - 你还得考虑统一性吧,总不能一些文件在独立目录,一些文件又在公共路径
    你单独发布的软件可以把需要的 so 全部打包在一起,发行版还这么干,那里面得有多少重复文件啊( nix 等另辟蹊径的暂且不提)
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5290 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 42ms UTC 07:14 PVG 15:14 LAX 23:14 JFK 02:14
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86