我有一个我为Windows编写的应用程序，我将其移植到Linux（特定于Ubuntu）。 问题是我一直只使用Linux，从来没有真正为它开发过。 更具体地说，我不了解系统的基本布局。 例如，我应该在哪里安装我的软件？ 我希望所有用户都可以访问它，但我需要该区域的写权限才能编辑我的数据文件。 此外，我如何以编程方式确定软件的安装位置（而不仅仅是从哪里调用）？ 在Windows中，我使用注册表来查找包含所有相关信息的配置文件，但Linux中没有注册表。 谢谢！
I have an application that I've written for Windows which I am porting to Linux (Ubuntu to be specific). The problem is that I have always just used Linux, never really developed for it. More specifically, I dont understand the fundamental layout of the system. For example, where should I install my software? I want it to be accessible to all users, but I need write permission to the area to edit my data files. Furthermore, how can I determine in a programmatic way, where the software was installed (not simply where its being called from)? In windows, I use the registry to locate my configuration file which has all of the relevant information, but there is no registry in Linux. Thanks!
最满意答案
文件系统层次结构标准 （错误名称 - 它不是标准）对您非常有帮助; 它清楚地描述了数据应该存在的管理员偏好。
由于您是第一次打包软件，我建议您做的很少 。 Debian，Ubuntu，Red Hat，SuSE，Mandriva，Arch，Annvix，Openwall，PLD等都有自己的小特性，关于如何最好地打包软件。
建造
您最好的选择是提供构建的源代码tarball，并希望这些发行版的用户或打包程序能够为您提供并打包它。 下载tarball，解压缩，编译和安装时，用户可能会没问题。
对于构建软件， make(1)是通常的标准。 存在其他工具，但是这个工具随处可用，并且非常合理。 （即使语法不完整。）用户希望能够运行： make ; make install make ; make install或./configure ; make ; make install ./configure ; make ; make install 默认情况下， ./configure ; make ; make install以将您的软件构建并安装到/usr/local 。 （ ./configure是autotools工具链的一部分;特别适合提供./configure --prefix=/opt/foo以允许用户使用一个命令行参数更改软件的安装位置。我会尽量避免使用autotools尽可能地，但在某些时候， 用它们编写便携式软件比没有它们更容易。）
打包
如果您真的想提供一站式打包，那么Debian Policy Manual将提供有关如何打包软件的规范规则。 Debian新维护者指南将为Debian和Debian派生系统构建软件包提供独特的工具，提供更友好，更温和的演练。
Ubuntu的包装指南可能包含Ubuntu特有的详细信息。 （我还没读过。）
组态
当涉及到应用程序的配置文件时，通常文件存储在/etc/<foo> ，其中<foo>表示程序/包。 有关名称解析的详细信息，请参阅/etc/resolv.conf /etc/fstab查看包含文件系统的设备列表及其安装位置， /etc/sudoers用于sudo(8)配置， /etc/apt/用于apt(8)包管理系统等
有时应用程序还提供每用户配置; 这些配置文件通常存储在~/.foorc或~/.foo/ ，以防整个目录比文件更有用。 （参见~/.vim/ ， ~/.mozilla/ ， ~/.profile等）
如果您还想提供-c <filename>命令行选项来告诉程序使用非标准配置文件，那么这有时会非常方便。 （特别是如果您的用户可以运行foo -c /dev/null来启动完全默认配置。）
数据文件
用户将其数据存储在其主目录中。 你不需要对此做任何事情; 只需确保使用getenv("HOME")启动目录导航框或通过sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application");加载配置文件sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); 或类似的东西。 （除了他们的主目录和大多数站点的/tmp/ ，他们没有权限写入。）
有时，所有数据都可以存储在隐藏文件或目录中; 例如， ssh(1)将其所有数据保存在~/.ssh/ 。 通常，用户需要ssh-keygen(1)的默认kry名称，因此ssh-agent(1)可以找到最小的密钥。 （它默认使用~/.ssh/id_rsa 。） shotwell(1)照片管理器提供管理体验，类似于Apple的iPhoto.app 。 它允许用户选择一个起始目录，但在其认为合适的情况下组织文件和目录。
如果您的应用程序是通用程序，您可能会让您的用户选择自己的文件名。 如果他们想要将数据直接存储到安装在/dev或/media的记忆棒或安装在/automount/blah的远程文件系统，其主目录，机器上提供的内容的/srv/目录，或/tmp/ ，让他们。 用户可以为他们的数据选择合理的文件名和目录。 用户已经拥有适当的权限。 （不要试图为用户提供在没有权限的位置写入的机制。）
应用程序文件安装和所有权
在Linux系统上安装应用程序有两种常用方法：
管理员为每个人安装一次。 这很平常。 这些程序由root或bin或adm或某些类似帐户拥有。 程序以任何用户执行它们的方式运行 ，因此它们获得用户创建和读取文件的权限。 如果它们与分发包装文件一起打包，则可执行文件通常位于/usr/bin/ ， /usr/lib/库和非对象文件（图像，模式等）将存在于/usr/share/ 。 （ /bin/和/lib/用于早期启动或救援环境所需的应用程序/usr可能对网络中的所有计算机都是通用的，在启动过程的后期以只读方式挂载。）（请参阅FHS完整版细节。）
如果程序是unpackaged，那么/usr/local/将是起点： /usr/local/bin/ ， /usr/local/lib/ ， /usr/local/share/等。有些管理员更喜欢/opt/ 。
用户将应用程序安装到其主目录中。 这种情况不太常见，但许多用户将拥有一个~/bin/目录，用于存储他们编写的shell脚本或程序，或者链接到~/Local/<foo>/目录中的程序。 （这个名字没有什么神奇之处。这是我多年前想到的第一件事。其他人选择其他名字。）这就是./configure --prefix=~/Local/blah为自己./configure --prefix=~/Local/blah 。）
The Filesystem Hierarchy Standard (misnamed -- it is not a standard) will be very helpful to you; it clearly describes administrator preferences for where data should live.
Since you're first packaging your software, I'd like to recommend doing very little. Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD, etc., all have their own little idiosyncrasies about how software should be best packaged.
Building
Your best bet is to provide a source tarball that builds and hope users or packagers for those distributions pick it up and package it for you. Users will probably be fine with downloading a tarball, unpacking, compiling, and installing.
For building your software, make(1) is the usual standard. Other tools exists, but this one is available everywhere, and pretty reasonable. (Even if the syntax is cranky.) Users will expect to be able to run: make ; make install or ./configure ; make ; make install to build and install your software into /usr/local by default. (./configure is part of the autotools toolchain; especially nice for providing ./configure --prefix=/opt/foo to allow users to change where the software gets installed with one command line parameter. I'd try to avoid the autotools as far as you can, but at some point, it is easier to write portable software with them than without them.)
Packaging
If you really do want to provide one-stop-packaging, then the Debian Policy Manual will provide the canonical rules for how to package your software. The Debian New Maintainers Guide will provide a kinder, gentler, walkthrough of the tools unique to building packages for Debian and Debian-derived systems.
Ubuntu's Packaging Guide may have details specific to Ubuntu. (I haven't read it yet.)
Configuration
When it comes to your application's configuration file, typically a file is stored in /etc/<foo> where <foo> represents the program / package. See /etc/resolv.conf for details on name resolution, /etc/fstab for a list of devices that contain filesystems and where to mount them, /etc/sudoers for the sudo(8) configuration, /etc/apt/ for the apt(8) package management system, etc.
Sometimes applications also provide per-user configuration; those config files are often stored in ~/.foorc or ~/.foo/, in case an entire directory is more useful than a file. (See ~/.vim/, ~/.mozilla/, ~/.profile, etc.)
If you also wanted to provide a -c <filename> command line option to tell your program to use a non-standard configuration file, that sometimes comes in real handy. (Especially if your users can run foo -c /dev/null to start up with completely default configuration.)
Data files
Users will store their data in their home directory. You don't need to do anything about this; just be sure to start your directory navigation boxes with getenv("HOME") or load your configuration files via sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); or something similar. (They won't have permissions to write anywhere but their home directory and /tmp/ at most sites.)
Sometimes all the data can be stored in a hidden file or directory; ssh(1) for example, keeps all its data in ~/.ssh/. Typically, users want the default kry name from ssh-keygen(1) so ssh-agent(1) can find the key with the minimum of fuss. (It uses ~/.ssh/id_rsa by default.) The shotwell(1) photo manager provides a managed experience, similar to iPhoto.app from Apple. It lets users choose a starting directory, but otherwise organizes files and directories within as it sees fit.
If your application is a general purpose program, you'll probably let your users select their own filenames. If they want to store data directly to a memory stick mounted in /dev or /media or a remote filesystem mounted into /automount/blah, their home directories, a /srv/ directory for content served on the machine, or /tmp/, let them. It's up to users to pick reasonable filenames and directories for their data. It is up to users to have proper permissions already. (Don't try to provide mechanisms for users to write in locations they don't have privileges.)
Application file installation and ownership
There are two common ways to install an application on a Linux system:
The administrator installs it once, for everyone. This is usual. The programs are owned by root or bin or adm or some similar account. The programs run as whichever user executes them, so they get the user's privileges for creating and reading files. If they are packaged with distribution packaging files, executables will typically live in /usr/bin/, libraries in /usr/lib/, and non-object-files (images, schemas, etc.) will live in /usr/share/. (/bin/ and /lib/ are for applications needed at early boot or for rescue environments. /usr might be common to all machines in a network, mounted read-only late in the boot up process.) (See the FHS for full details.)
If the programs are unpackaged, then /usr/local/ will be the starting point: /usr/local/bin/, /usr/local/lib/, /usr/local/share/, etc. Some administrators prefer /opt/.
Users install applications into their home directory. This is less common, but many users will have a ~/bin/ directory where they store shell scripts or programs they write, or link in programs from a ~/Local/<foo>/ directory. (There is nothing magic about that name. It was just the first thing I thought of years ago. Others choose other names.) This is where ./configure --prefix=~/Local/blah pays for itself.)
更多推荐
发布评论