Re: symlinks in upstream and cvs-buildpackage

2002-05-14 Thread Manoj Srivastava
Hi, You can use $CVSROOT/CVSROOT/modules line to add -e and -o scripts to recreate the symlinks on checkout. Works great with symlinks and such. You can then use the pristine upstream sources. This is nothing specific to cvs-buildpackage -- just ordinary cvs-fu. mano

Re: symlinks in upstream and cvs-buildpackage

2002-05-14 Thread Matt Zimmerman
On Tue, May 14, 2002 at 08:27:45PM -0500, Paul Baker wrote: > Since dpkg-source ignores that I have removed the symlinks, when I later > do the `cvs-inject mapserver_3.5-1.dsc` it of course dies on the symlinked > files. I can use cvs-inject -F to have it remove the symlinks, but I'm > wondering

symlinks in upstream and cvs-buildpackage

2002-05-14 Thread Paul Baker
I trying to create a debian package for the MapServer project (http://mapserver.gis.umn.edu/). I want to use cvs-buildpackage to track my changes with CVS. cvs-inject does not allow there to be any symlinks in the directory structure when importing the sources into CVS. MapServer 3.5 unfortune

Re: handling file name conflict

2002-05-14 Thread Jérôme Marant
Alexandre <[EMAIL PROTECTED]> writes: > Hello, Hi, > What would be considered the best way to handle this ? You can call it pyro.ns . I've already experienced such a case in one of my packages. Cheers, -- Jérôme Marant http://marant.org -- To UNSUBSCRIBE, email to [

Re: Depends: on package in contrib

2002-05-14 Thread Stefan Schwandter
Steve Langasek wrote: > If you build snd-gtk and snd-dmotif from the same source package, then > all of the packages must go into contrib: a source package in main can > also not build-depend on packages outside of main. The practical > reason for this is that Debian's autobuilders are not guara

handling file name conflict

2002-05-14 Thread Alexandre
Hello, I'm working on packaging pyro (http://pyro.sf.net), which is a distributed obvject framework for Python. The directory service daemon for pyro is called 'ns' (NamingService) which is quite unfortunate because /usr/bin/ns is a file in the very useful host package. I've talked about this

Re: Depends: on package in contrib

2002-05-14 Thread Thom May
* Stefan Schwandter ([EMAIL PROTECTED]) wrote : > Hello, > > > policy says that a package in main must not declare a releationship on a > package not in main. > > I would like to split the snd package into a snd (arch-independent > files), snd-gtk and snd-dmotif, where snd-dmotif is in contrib.

Depends: on package in contrib

2002-05-14 Thread Stefan Schwandter
Hello, policy says that a package in main must not declare a releationship on a package not in main. I would like to split the snd package into a snd (arch-independent files), snd-gtk and snd-dmotif, where snd-dmotif is in contrib. Is it legal to declare a Depends: on snd-gtk|snd-dmotif in the