Re: RFS: snetmanmon, a simple network manager and monitor
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 ;)
cheers!
Gianfranco
Reply to: