On Wed, Dec 24, 2008 at 10:35 PM, Sandro Tosi <mo...@debian.org> wrote: > On Wed, Dec 24, 2008 at 00:48, Ondrej Certik <ond...@certik.cz> wrote: >> thanks for the points, I reacted to some. > > so please accept my reply :)
Absolutely. :) > have you ever tried git-svn to work over your packages actually in the team? Yes, git-svn rocks and I use it regularly, but branching+merging sucks with git-svn, plus you cannot really use it with git-buildpackage, upstream branch and pristine-tar. Also if you reclone it, you have to follow the howto here in order to dcommit back to svn: http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone > Really? for a bunch of file under debian/ you need all of this? or are > you talking about upstream code? I think we need to separate the 2 > arguments, because the *are* separated: we are packagers, we have to > keep track of our team's things; your involvement in upstream > development is commendable, but this is something "other" that debian > packaging, so it has to be. Yes, I do use it just with the debian dir, to see what other people have done with the package. >> However, sometimes the orig.tar.gz cannot be obtained with svn-uscan >> --- let's say if you are repackaging upstream, or simply if you are >> packaging a different version than svn-uscan downloads. > > well, either you're creating a new revision of an already existing > package (so apt-get source --tar-only would do) or you should stick to > the lastest released tarball, ain't you? There should be strong reason I want to be able to also easily build let's say the new numpy version (1.2.1) together with the one in the Debian archive, e.g. 1.1.1. Because the 1.2.1 requires a bit more work, I cannot yet upload it to Debian. So now we have 2 orig.tarballs already. You are right, that in this case I can get both just with apt-get source or svn-uscan. > to not package the latest version but one between the latest and the > one in the archive, that could he handled as expection: they are not > the regular way to do, so we cannot take them as examples. In fact, svn-uscan downloads the one specified in debian/changelog, so I can get any orig.tarball I need, as long as upstream webpages have it. The problem is that I need an internet connection and upstream needs to have working webpages. With git+upstream branch, I can just clone the repo and go off the internet and I am safe, because I have everything needed to build any version. So it boils down to a question of size, e.g. harddisk and net connection speed/price. > >> One example >> being the abinit package, where svn-uscan is offering me the highest >> released version number, however the production version (that should >> be packaged) is not the highest version available. > > this seems to be a very corner case Ok. > >>> I don't see too difficult: 1 command (whatever you prefer) comparing >>> with the many of "vi <file> + dch + build + lintian" loops you do to >>> prepare a package. >>> >>>> everything will be in one git repo, >>> >>> Given my slooooow line, I cannot afford the pain to download every >>> packages source code + debianization; now, to have a full checkout of >>> dpmt/papt repositories, I need to launch the commands during the >>> night. Additionally, doing repositories wide updates will become more >>> painful, so I have to refrain from "work on every package" but just on >>> mine. >> >> That's a good argument and I don't know the answer to it. But are you >> sure it would be that much bigger? > > Ondrej, you're a science man :) are you just kidding here? :D Of > course it's bigger. A lot bigger. Given you have the whole repository I just asked a question and as a science man, I was curious about the answer. You say "Of course it's bigger. A lot bigger.". So that made me think, hmm, let's just try it and see. So I took the last 4 upstream releases of numpy, and imported the orig.tarballs one by one into one git repository, together with the binary-delta (e.g. pristine-tar). version, git size, orig.tar.gz size 1.0.1 1.5M 1.2M 1.1.0 2.2M 1.7M 1.1.1 2.3M 1.6M 1.2.1 2.6M 1.4M So as you can see, the whole repository with all 4 versions is less than twice as big as any orig.tar.gz. I do not consider this "a lot bigger". > locally, you have the HEAD + all other modifications done in the past, > for both the upstream code and the debianization. It's like No, only upstream orig.tar.gz is imported, so we do not care about upstream revisions -- that's not our problem. > downloading all the uploaded version of the package in the archive > compared with only the latest one. As you can see from my example with numpy above, this doesn't seem to be the case. The amount of downloaded data is *less* than two orig.tar.gz in the numpy case above. > > Let's take the example of DPMT: the dimension on the svn repo on > alioth is 186M while the full checkout I have here is 47M. And that's > only for debian/ dir (well, almost, but still). Well, but you need to count the orig.tar.gz that you need to download as well in order to build any package. The only example I can see is when doing some changes without actually building the packages, e.g. adding the vcs links to debian/control and similar things. >> If you want to test a package, you >> still need to download the orig.tar.gz plus the debian dir (in svn). >> (the best thing is to just try this and see) > > But I can only take the latest tarball and debian/ dir not the whole > past: if I want to forge a patch for a package, I don't need and I > don't want to know every single bit that compose the history of it, I > want his source package and work on it, stop :) It's almost the same > for the team: I want to work on the latest version possible. Sure. As I said above, in the numpy case it is less than twice as big. So for me, that is absolutely no problem. Unless you want to only work on the debian dir without the orig.tar.gz, but well, I think that is a corner case, because most of the time I want to build the package. >>> What users are you talking about? those that wants to rebuild a >>> package are experienced used, so they can apt-get source <pkg> and >>> then debcheckout it or whatever order/way they prefer. A normal used >>> is "client" of the .deb package installed via >>> apt-get/aptitude/synaptic/dpkg/ >> >> I am talking about the user (client in your terminology:), who reports >> a bug and even suggests a fix, but he doesn't have time to learn how >> to fiddle with svn-buildpackage+orig.tar.gz. Especially if the fix >> needs to change some patches in debian/patches. > > so you're expecting the same very user to know git so good to clone > the repo, branch it to forge a patch, mail you the diffe between the > current and his branch? I don't think it will ever happen, of if he > can do that, he can managed to do the same as it's now. Let's make a friendly bet. :) I am saying it will happen, as an example, take this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507746 so Janis not only reported a bug, but also sent us a patch, after I explained how to create the patch. > Honestly, how many users really do this? or even think about it? They > don't even know that reportbug/BTS exists (sadly) ;) Those users are > "We", the package maintainer I disagree with this. I treat every user as a potential (debian) developer. I also think everyone who is able to report a bug in our BTS is able to send a patch, if he knows how to fix it -- e.g. many times people know the right fix, they only don't know how to technically fix it in the debian packaging. The point of all of this is that people can fix and test the packages themselves and thus saving time of Debian Developers. And also all those people are then potential developers. > I think that's what we should care about; upstream work should be done > separately from debian work, that's my point, so it follows directly > from this that I don't feel the need to change, simply :) A already > said, if some packagers of particularly complex packages need > particular solutions, we can find them together, but for the tons of > small modules (mainly) that's a huge overkill. In case of numpy imho it is not an overkill, see above. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
