Upstream has given me write permissions on the CVS server. They'd like to have 'debian/' included in the CVS tree, so people could build their own snapshot debs. I think this is a great idea. "This thread":http://lists.debian.org/debian-mentors/2000/debian-mentors-200006/msg00000.html suggests it may *not* be a good idea. Any thoughts? --MichaelIvey
My concerns are:
1. What happens if I hand off the package to another maintainer?
1. What does this do to ?NMUers?
1. What goes in the diff?
Another thread: http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg00503.html
Another somewhat related thread: http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00128.html
--- Well, the problem is IMHO that people like to build their cvs snapshots differently. When the debian/ dir is NOT in the CVS tree, but maybe in a separate CVS, each user can still use the CVS functions of the main repository, and have his own debian/ dir. Whereas if there is a debian/ dir in the CVS repository you'll update it on each "cvs up", too... This means that if you do want a different debian/ dir, you'll have to move your debian dir aside, do cvs up, remove the upstream debian/ dir, move yours in place, build... that's pretty annoying. When the debian dir is separate there is no problem. But this is a problem for end-users, not the Debian maintainer, correct? IE: if upstream wants 'debian/' in CVS, it shouldn't matter to the Debian maintainer one way or the other? --MichaelIvey
---
I think the problem is not so much an debian in upstream's cvs, but an debian-subdir in upstream's released files. If the old maintainer did something the one way and an new maintainer wants to do it another way, the new maintainer has first to contact upstream to remove the debian-subdir or make it's own .orig.tgz or has to delete files from debian/rules (diff does not support removal of files). Neither of this three options is any good at all.
---
Who cares if upstream include debian/ in CVS? Debian developers should be packaging released source, i.e. from tarballs.
Now, if the released tarball has debian/ in it, you can either ask upstream to not package debian/ and leave it only in CVS (trivial if they use auto*), or you can delete useless files that they include, in debian/rules before you build. If their debian/ is close to yours, then you will save storage by having a smaller diff, too.
In this case, upstream's 'debian/' *is* my 'debian/' ... I'll be writing it directly to upstream CVS. But I understand your point. --MichaelIvey
---
This is a good idea. The problem is not to build a different debian package but FIRST to build ONE. rpm's maintainers do not seem to have these philosophical questions... It's much more easier for a rpm's-like user to build a package than for a debian's user : why ?
- If you want to build the package differently then probably you have sufficient technical knowledge about CVS to overload the CVS upstream debian/ ! (very easy juste "replace" debian/CVS files by others)
The problem is not a technical one. I think that, on this point, there is a contradication in «Debian's attitude». On one hand we want to have a closer collaboration with upstream, but on the other hand we do not want to put debian/ on upstream CVS...
For example, as a Debian user, I want upstream to (be able to) give his opinion about the activation of ./configure options in the debian package... GeorgesMariano
debian directories in upstream tarballs should be more manageable now that debhelper has the --ignore switch. See http://kitenet.net/~joey/blog/entry/on_debian_directories_in_upstream_tarballs/ for more details. --JoeyHess