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".