[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: snetmanmon, a simple network manager and monitor



Am 13.01.2016 um 11:27 schrieb Gianfranco Costamagna:
Hi,

-format should be 3.0 quilt not native

That doesn't work. I already have had spend time before with trying to
use 3.0 and it didn't played well with the build system I'm using for
snetmanmon (cmake).


it works, I can confirm you it works, on many projects I maintain.
Maybe you just need to have a source orig tarball?

examples of projects cmake based I maintain in quilt mode: ettercap, casablanca,
websocketpp, hedegewars, cld and many others


Ah, yes, have forgotten that. But if you'r building snetmanmon from
source (and with source I mean its git repository) you already have git
installed. I've not spend time to look up how to build a working source
package (which would not require git). So something else might be needed
for a source package (e.g. a fixed file named 'version').


no. debian builders have no git installed, they have a minimal set of packages,

and if you want your package to build on debian you need to provide a orig tarball,
and set the version somewhere.


override_dh_auto_install:
mkdir -p debian/snetmanmon/etc
cp snetmanmon.conf.full_example  debian/snetmanmon/etc/snetmanmon.conf

I would prefer being upstream to install the file in etc,
and for sure use of "install" instead of cp

That cp there isn't used to install anything in the target system. It
just is used to copy the file into the directory used to build the

debian package.

this is non-sense to me, you can't ever install stuff on target system (unless
you go home-by-home and install it :p )

you install on debian/package/ the resulting filesystem of your package, and that
is installed with dpkg when the deb file is extracted.

For sure I would appreciate use of "dh_install" such as is done in websocketpp package.

but even more I would appreciate your build system (the upstream one)
to do something like
INSTALL(FILES whatever DESTINATION etc)
(look e.g. ettercap/share/CMakeLists.txt)

this will install the stuff in ${DESTDIR}/etc IIRC

and you won't need to override it in rules file, just tweak the install file if needed.

the cp e.g. is wrong in many cases, e.g. doesn't set the correct file permissions.
if you commit a chmod 755 of a config file on your repository, the file will probably end
up with the wrong permissions on user systems.

install -m0644 is better, but cmake install("FILES" should work also on other linux distros
(and maybe not only linux of course)


Reason is the same as I mentioned before in regard to >the copyright. I don't want files with the same content in my source
repository just because the debian package build system requires them.
That means I want the various example configuration files wherever I
seem them to fit in the source repository of snetmanmon, but not where
Debian or some other package build system requires them. The resulting
package will install them just fine in /etc.


in this case you need (and probably this is the best option) to have the Debian packaging separate
from your upstream development, and then use
gbp import-orig orig-tarball to import the new release into your Debian packaging
(there is a ton of documentation regarding this)

this way you release your upstream tarball, import it in the Debian packaging with quilt, and upload
on debian.

the pro is that you don't have to release a new tarball each time you have to deal with a Debian upload
(other Linux distros might not appreciate a release just for Debian changes)

and that you don't have to poison your source tree with "useless files" (useless in upstream context).

the cons is that you have to maintain two branches, but at the end it is the best feasible approach.


Will test it. Will see when I find the time.

no problem, take your time :)

the first package is somewhat difficult to achieve ;)

Sorry, but all your talk about non-sense is just non-sense for me. Both of you don't seem do have understood why that cp you want to change to install is there. It is not there to install a file in the target system, it's there to build a directory structure to make dh_foo happy in order to build a installable debian package.

Regards,

Alexander Holler


Reply to: