Re: camsource -- a modularized and multithreaded webcam-streaming software
On Wed, Sep 24, 2003 at 02:28:34AM +0200, Thomas -Balu- Walter wrote:
> On Tue, Sep 23, 2003 at 07:45:28PM +0200, Andreas Metzler wrote:
>> [...]
>> You may generate the devices in postinst without asking the user, you
>> just have to depend on makedev.
> I am not sure wether this should be done. I am thinking of devfs-users
> (or does makedev handle this?)
You'd have to use something like if [ ! -c /dev/.devfsd ] ...
> or users who don't want to stream video,
> but e.g. screenshots of their desktop which can be handled bei camsource
> too. All of them don't need the video-devices to be created. (I did,
> thats why I included it in the README ;)
It is your call.
> > About README.Debian:
> > | usermod -G video <username>
> > I'd suggest "adduser <username> video" instead, it really only _adds_
> > the user to the group.
> Sure, thanks. After 10 years of unix I've just learned a new
> adduser-option after keeping removing myself from auxiliary groups
> while trying to add one ;)
That is just Debian's nice adduser/useradd, RedHat's does not provide
this ;-)
[...]
>> If you are providing are shared library and expect other programs to
>> link against it, you'll need to provide a shlibs-file, e.g. by using
>> dh_makeshlibs.
> I don't think other programs would benefit from the plugins to
> camsource. Because the shared libraries are limited (IMHO) to camsource
> I included them into the main deb and not into a special
> libcamsource-package:
[...]
> But 10.2 says:
> Such files [e.g. plugins] are exempt from the rules that govern
> ordinary shared libraries.
>
> Can I ignore the above 8.6-statement then or is it better to just enable
> dh_makeshlibs anyway? (Just did that, but don't know if it is okay this
> way? - I'd better listen to the "binaries only first package"-speaks ;)
It depends on the intended usage of the stuff in /usr/lib/camsource/.
Is it a plugin or a library against which plugins are supposed to
link? It looks like you are putting a real shared (and static) library
in there.
If it is a plugin 10.2 scores (but then why are you shipping a static
library?) if it is not you must provide a shlibs-file. Afaict you'd
have to move the library to /usr/lib/, too. But shared library
packaging is not my area of expertise, I do not manage one and would
suggest consulting
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
>> Otherwise nice first shot, afaict just from browsing the diff ;-)
> Thanks. I've updated the packages regarding your suggestions, they
> can be found in http://www.b-a-l-u.de/debian/camsource/
> I did not update the version of this new build. What is the common
> way to handle such "not yet uploaded 'beta' packages"? Give them version
> numbers below 1, simply ignore versioning?
I've used -0.0.1 or -0.1 but would not recommend this, these numbers
are reserved for source and binary NMUs, I would either use regular
versioning or something like -0.balu.1, -0.balu.2, etc. and once you
you think the packageare to be ready for uploading sum up all the
-0.balu.* into one -1 changelog entry.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Reply to: