1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
local-apt-repository
====================
Ready to use local apt repository
With this package installed, every Debian package (i.e. a *.deb file) dropped
into /srv/local-apt-repository (which you need to create first) will be
available to apt.
This package does not provide an apt repository to be used by other hosts. For
that, look at more serious repository solutions like reprepro and
apt-ftparchive.
If you want to use this package on a system without systemd running, you will
have to manually run /usr/lib/local-apt-repository/rebuild when you add new
packages to /srv/local-apt-repository.
APT pinning
===========
local-apt-repository uses its name as Origin when generating the Release file.
Thus, an entry like
Package: *
Pin: release o=local-apt-repository
Pin-Priority: 500
for apt_preferences(5) can be used to adjust the priority of local packages.
On the use of /srv
==================
Packages to be added to the repository fit the description of /srv
quite perfectly. I quote:
/srv : Data for services provided by this system
Purpose
/srv contains site-specific data which is served by this system.
This main purpose of specifying this is so that users may find the
location of the data files for particular service, and so that
services which require a single tree for readonly data, writable
data and scripts (such as cgi scripts) can be reasonably placed.
Data that is only of interest to a specific user should go in that
users' home directory.
[..]
So it is not wrong to use this directory. Also, all alternatives are
wrong in some way as well.
The only thing that I’m currently doing wrong is that I hard-code the
path (“Therefore, no program should rely on a specific subdirectory
structure of /srv existing or data necessarily being stored in /srv.”).
If the package would make the path configurable, then it’d be in
compliance with the FHS.
Practically, I expect the intersection of those who want to use this
package, and who need to have a different layout in /srv to be empty.
So if I make the path configurable, it is adding complexity purely for
policy compliance, and hence it is low priority for me.
(My plan for doing that is to have the authorative path in the local
-apt-repository.path sytemd unit, which the admin can override using
usual systemd foo, and can be read from the repository creating
script.)
|
