On 20/02/2013 23:45, Scott Kitterman wrote: > On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: > [...] >> 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.
Not always. Text compresses easily, so it is not uncommon for the .git to be
smaller than a single uncompressed checkout of the tarball. And with
pristine-tar, you end up having every single tarball in history contained in
that .git directory.
>>> 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.
In the pkg-cli-{apps,libs}, we keep upstream history separate from downstream
history. Only the tarballs are imported, and that is done using git import-orig
--pristine-tar. Patches are maintained using gbp-pq or quilt. At the end of the
day, there isn't anything that only lives in the VCS.
>>> "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 (as
> I've
> seen some people do who use Git) then any Debian changes to the upstream code
> are difficult to parse and undocumented. When you have patches, they are
> documented in debian/changelog and in the patch comments exactly why they are
> there (I know sometimes this isn't done, but it is supposed to be).
Actually, with git-buildpackage, there's a gbp-pq tool which allows you to
import a quilt series of patches into a temporary patch-queue/$branch in git,
allowing you to use git rebase and whatever other git tools you have to figure
out what changes go where. After which, they can be exported into debian/patches
again and committed.
> [...]
> I've had it explained to me how to do it, done it, and then the next time I
> needed to do it could no longer remember it. For people that do packaging
> all
> day, every day, I think many of these tools are great, but for people like me
> for whom this is not the main focus of their day there's too much complexity
> involved to be useful.
That argument applies to any VCS that you don't use on a daily basis. You use
bzr on a daily basis and forget how to use git. I use git on a daily basis and
forget how to use svn/bzr and have to relearn it any time someone forces me to
use one of those. I don't think this is a valid reason for avoiding git.
>> By the way, I do the packaging of MLMMJ, and upstream provides both
>> mercurial
>> and Git, which I think is really awesome. If we could have that, and not
>> only Git,
>> that would be best, IMO, so that those who likes hg could use it. Last
>> time I
>> looked, it didn't seem so hard to setup. Probably that would be a nice
>> addition
>> to Alioth as well, so that any Alioth project using Mercurial would have
>> Git too.
>> Do you also think it would be worth asking the Fusion Forge team?
>>
>>> I've used partial (debian dir) VCS branches for years in both Debian and
>>> Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
>>> all to full source.
>>
>> WIthout full source, how do you use git-buildpackage? Could you describe
>> your workflow so that I can understand your view as well?
>
> I don't. 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).
That sounds like awful lot of steps to take. My workflow only involves editing
things directly in the git repository, and then running git-buildpackage to
build. With the export-dir option that I have set in ~/.gbp.conf, that
automatically exports it out to ../build-area/ and builds on the spot.
Committing can be done with debcommit or any other method of committing into a
git repository.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
