On 02/20/2013 11:45 PM, Scott Kitterman wrote: > On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: >> On 02/20/2013 10:43 PM, Scott Kitterman wrote: >>> First, full source repositories are much larger than debian only >>> repositories. I don't have a full checkout of all team packages locally, >>> so that means if I'm going to touch a package I don't have to download, >>> it's more time, bandwidth, etc. Even for a new upstream version, debian >>> directory in the repository and upstream tarball is still smaller. >> If you are modifying some packages, it's to upload them at some point. >> In such case, you will need the upstream tarball, right? I don't see where >> the waste of bandwidth is then. > A VCS with all the upstream history will always be bigger than the tarball > for > just the current release. Sometimes substantially so.
But you only very rarely clone from scratch, and only get some incremental changes. While with tarballs, you always have to get the full of it. > >>> Second, I think Debian packaging work and upstream's product should be >>> distinct in the source package. The source package is what Debian as a >>> project ships as the source for DFSG purposes and it should be useful. >> Which is why we have branches. One with the upstream code, and one >> with the debian folder added. Everything being contained in that debian >> folder. So it's really distinct. > You're missing my point. If it's only in the VCS, it's not in the source > package. The source package needs to stand alone without the VCS to, in my > opinion, properly comply with the spirit of the DFSG. It's funny that you say it this way. I've read some other opinion saying that with the tarball, you're missing lots of information from upstream. That person went up to say that he thought it'd be a good idea to package the git repository as source package (sorry, I can't remember who and when, just that it was in -devel@l.d.o). I quite agree with this view. >>> "Here's a huge mass of code and to understand what we did to it, you need >>> to refer to this external repository (VCS)" is not socially acceptable to >>> me. >> It's not any different to have absolutely zero upstream code in the VCS: >> you will need to refer to an upstream tarball, which has "a huge mass >> of code". > Right, but if you embed Debian specific changes and don't use patches That's not what I do. > I know sometimes this isn't done, but it is supposed to be I agree it's a bad idea, so we are on the same line. > I generally unpack the upstream tarball, export the debian dir from > the VCS into the unpacked tarball, update the package, build it with dpkg- > buildpackage, and then commit the changes back to the VCS repository with > debcommit (which is very nice since it speaks to multiple VCS through the > same > interface). So, basically, you're doing all by hand... That's very tedious. IMO, the whole point of using git (or any other VCS), is to use either git-buildpackage, or "git-stuff" (that's a package name...), so you have tools to do all this manual boring work. git-stuff works the opposite way. You'd do all the changes in your packaging, then it would write the debian/changelog based on the commit messages. I find it a lot better, because then you can have a history of you changes, do rebase, squashes, cancel, etc. without the risk to loose any of your changes. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51250a67.1060...@debian.org
