David Plans Casal wrote:
still, why not just write a small script to pull the external sources from upstream? (ftp, cvs, svn or whatever)
I would rather see that too, of course. Has hc not explained why he - isn't- doing that already?
iirc, the main argument against this is, that debian does not allow to fetch additional "helper" sources from the net.
hc's other point is, that making these sources available in the CVS, is necessary because people not using debian have a hard time getting these sources.
my conclusion is: on systems that have a reasonable package-manager (like debian) use that one; on systems that don't, use the checkout-scripts. so, i don't see a realy conflict here (meaning: i don't see a reason to _not_ use checkout scripts)
afaik, debian's policy generally doesn't really like to use sources directly from CVS (i might be wrong here, though). therefore, for using pd-extended for debian builds, a "source-ball" should be done anyhow (e.g. via a monthly script). this source-ball could then include all the (hard) dependencies that cannot be expected to come with your distro/OS.
i totally agree with frank, that the pd-cvs should not become a place to host dssi-plugins. i also feel towards tim, that projects available otherwise (esp. if they are hosted on sourceforge - which pretty much guarantees their availability, even if the connection is often beyond discussion) should not be incorporated.
however, i think there might be one simple solution: urge the sourceforge staff, that they make /cvsroot/ available as CVSROOT; this way, you could do a: "cvs -d:pserver:anonymous@cvs.sf.net/cvsroot co ." and fetch the world (or use some modified command, to only get the relevant parts)
mfg.a.dsr. IOhannes