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

Re: More Vcs-Fields in debian/control?

Joey Hess <joeyh@debian.org> writes:

> I would instead suggest we deprecate packages not including upstream
> source in their VCS. The weight of progress is against that practice;

It is? Where can I read about this supposed weight of progress? Keeping
the debian packaging files in a separate repository suits me just fine.

> tools have improved so there is little excuse to do it

Which tools in particular? Are you accounting for the full suite of
VCSen that Debian's ‘VCS-*’ fields allow for?

> it increasingly violates expections and makes things harder.
> Some examples:
> * git cherry-pick cannot be used

I can't speak to that one as I don't know what the problems are.

> * pristine-tar cannot be used

The assumptions of ‘pristine-tar’ seem very Git-centric and are quite at
odds with my chosen VCS (Bazaar). It demands a “treeish object”, I have
no idea what that relates to in Bazaar.

> * 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.

That sounds like a poor recommendation, then :-)

> Adding baroque complications to the VCS fields doesn't deal with these
> problems consistently

I agree that it's undesirable to add baroque complications to the
‘VCS-*’ fields.

 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\    Brain, but if the plural of mouse is mice, wouldn't the plural |
_o__)                      of spouse be spice?” —_Pinky and The Brain_ |
Ben Finney

Attachment: pgpIsJiZrO2st.pgp
Description: PGP signature

Reply to: