Index: trunk/doc/developer/packaging.txt
===================================================================
--- trunk/doc/developer/packaging.txt	(nonexistent)
+++ trunk/doc/developer/packaging.txt	(revision 7115)
@@ -0,0 +1,94 @@
+Packaging sch-rnd for a distribution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1. program, libs, desktop integration
+
+Sch-rnd is an interactive schematics capture (editor) program. A typical
+user is an electric engineer. This sort of programs are often called EDA,
+Electronics Design Automation.
+
+Sch-rnd has different frontends: graphical and stdio/text based batch
+processing. There are different graphical frontends - sch-rnd does not
+depend on gtk or motif, the specific frontend modules may depend on them.
+
+Sch-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.
+
+Sch-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 sch-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
+
+Sch-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 sch-rnd package and then optional
+extras on demand, reducing dependencies.
+
+The preferred package splitup is documented in packaging/,
+please follow that as closely as possible so different systems can
+deliver similar sch-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 sch-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://www.repo.hu/sch-rnd/tags .
+
+Sometimes we have minor releases with 2..3 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://www.repo.hu/projects/sch-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".
+