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"
