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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
Packaging pcb-rnd for a distribution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. program, libs, desktop integration
Pcb-rnd is an interactive printed circuit board editor program. A typical
user is an electric engineer. This sort of programs are often called EDA,
Electronics Design Automation.
Pcb-rnd has different frontends: graphical and stdio/text based batch
processing. There are different graphical frontends - pcb-rnd does not
depend on gtk or motif, the specific frontend modules may depend on them.
Pcb-rnd is scriptable if system installed libfungw is available. Since
libfungw is not a mainstream library, it is most probably not already
present in your distro and it should also be packaged too.
Pcb-rnd is intended for UNIX-fans. It is heavily keyboard-oriented and it
doesn't assume its users don't want to understand or learn how it works.
Many typical user workflows include Makefiles and it's a common thing to
start pcb-rnd from a shell. Thus desktop integration is not in focus
at the moment. If you fixed things for this while packaging, please let
us know, we may merge your patches (see below).
2. options, plugins, dependencies
Pcb-rnd is a modular software with a lot of options. Majority of these options
are selected by the state of a module. A module has three states:
- disable: (not compiled at all)
- buildin: enabled and static linked
- plugin: enabled and dynamic loaded (from a .so)
The configure script takes --disable-*, --building-* and --plugin-*
arguments with * substituted with the name of the module. The configure
script also determines the dependencies according to the selection. Special
arguments --all=plugin and --all=buildin are provided in configure to select
all working modules to be plugins or buildins.
For binary distributions it's strongly recommended to have most of the
modules compiled as plugins and have them in separate packages. This
would let the user to install a core pcb-rnd package and then the GTK
or the lesstif plugin (or both) from separate packages. This also reduces
package dependencies.
The preferred package splitup is documented in packaging/,
please follow that as closely as possible so different systems can
deliver similar pcb-rnd packages.
This is less relevant for source distributions, if the user has full control
over the configuration.
If non-critical dependencies are not met, modules are automatically disabled
by ./configure.
3. typical ./configure options - scconfig vs. auto*
./configure --prefix works as expected. DESTDIR works as expected.
Typical commands for configuring pcb-rnd for packaging would be:
./configure --all=plugin --prefix=/usr
make all
DESTDIR=/tmp/pkg_tmp make install
We are happy with scconfig. Please don't write about how much better
autoconf or cmake would be, we won't switch.
4. release cycles, tarballs, svn trunk - what to package
Development happens in svn trunk/, there are usually no branches. While
we try to keep trunk/ compilable any time, it's not guaranteed that it
would work out-of-the-box between releases. It is not recommended to
package trunk/ - please package stable releases instead.
We follow the "release early, release often" rule. Source release tarballs
are always considered stable. Beside the project web page, releases are
also accessible as svn tags: svn://repo.hu/pcb-rnd/tags .
Sometimes we have minor releases with 1..2 month period, sometimes a
longer period passes between releases.
There's no automated release notification at the moment; if you want to
get notified about new releases, please contact me
(http://repo.hu/projects/pcb-rnd/contact.html)
5. bug reporting and fixes for packaging
There's no special method for reporting packaging related bugs and
feature requests, please follow the normal bug report instructions or just
drop me a mail. Please mention that the issue is related to packaging, this
usually gives it a higher priority.
We are willing to make minor changes to make packaging easier - if you bump
into something you'd need to work around while packaging, please let us know,
we may just fix it "upstream".
|
