[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More Vcs-Fields in debian/control?



OoO En  cette aube naissante  du jeudi 07  avril 2011, vers  07:46, Joey
Hess <joeyh@debian.org> disait :

>> We (lindi, liw and me) had just a short discussion in #-devel, that it
>> would be nice to have some sort of Vcs-Upstream-* in debian/control, to
>> be able to get to upstreams vcs history if it is not imported in
>> debian's vcs (which is often the case when using svn-bp or git-bf with
>> import-orig). [background: lindi is doing some git-copyright checks and
>> it fails heavily if there is no upstream history as the debian
>> maintainer is asumed to be the copyright holder for everything]

> I would instead suggest we deprecate packages not including upstream
> source in their VCS. The weight of progress is against that practice;
> tools have improved so there is little excuse to do it, it increasingly
> violates expections and makes things harder.

> Some examples:

> * git cherry-pick cannot be used
> * pristine-tar cannot be used
> * apt-get source now suggests running debcheckout when VCS fields are
>   present. But for such a package, debcheckout won't result in the same
>   source tree as does apt-get source.

> Adding baroque complications to the VCS fields doesn't deal with these
> problems consistently, and while it might help this style of VCS use
> linger a while longer, it will be an unnecessary complication going
> forward.

Large SVN  repositories containing only debian/  directories are already
quite slow (at  least on alioth). Adding upstream  sources (and history)
would not improve this part.

Moreover, do we have space to cope with this?
-- 
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
-+- Bart Simpson on chalkboard in episode 4F03

Attachment: pgpnHXu5HRsen.pgp
Description: PGP signature


Reply to: