Giacomo Vacca

The good news is that building a debian package from the source of a CPAN module is easy, thanks to the dh-make-perl tool. The bad news is that the configuration of dh-make-perl can lead to the generation of a debian package containing unneeded files, and as a collateral effect preventing package installation as the files belong to more than one package. For example you can end up with something like: dpkg: error processing /var/cache/apt/archives/scnlibpoe-filter-stomp-perl_0.01_all.deb (--unpack): trying to overwrite `/usr/lib/perl/5.8/perllocal.pod', which is also in package scnlibpoe-component-client-stomp-perl Somebody suggests a change in the configuration file used by dh-make-perl . The same result can be achieved by applying this change to your debian/rules file: --- debian/rules (revision 32211) +++ debian/rules (working copy) @@ -51,8 +51,11 @@ - rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5 + rm -rfv $(TMP)/usr/lib

The goal is to make my life easier when the same package may go to different distributions. This is not useful per se, but it becomes so when you use custom distributions names to distinguish separate product branches. Let's assume you have an application app , which has different flavours, for example alpha and beta . You may want to have two separate debian repos for app , one called alpha and one called beta . Hosts within environment A may refer to the alpha repo, while hosts in another environment, let's say environment B, may want to refer to the beta repo. This keeps the small or big differences in app isolated. Now, assume app reaches a point when the only difference between A and B is the distribution name, so you can have the same version for the alpha and beta repo: how can you avoid building the package twice? Is there a way to make both repos happy? These are the questions that led me to the need of having a local debian repo , to experiment a little on this to...