FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-06-2011, 10:06 AM
Evgeni Golov
 
Default More Vcs-Fields in debian/control?

Hi -devel!

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]

My suggestion would even go further (attention, I have NO idea how
debian/control is parsed and how much work the following would be):
Let's make that Vcs-<Vendor> with <Vendor> (like in DEP3) Debian,
Upstream, Ubuntu, Whoever-else-uses-the-packaging.

Opinions?

Regards
Evgeni


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D9C3B1F.4060301@debian.org">http://lists.debian.org/4D9C3B1F.4060301@debian.org
 
Old 04-06-2011, 10:28 AM
Benjamin Drung
 
Default More Vcs-Fields in debian/control?

Am Mittwoch, den 06.04.2011, 12:06 +0200 schrieb Evgeni Golov:
> Hi -devel!
>
> 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]
>
> My suggestion would even go further (attention, I have NO idea how
> debian/control is parsed and how much work the following would be):
> Let's make that Vcs-<Vendor> with <Vendor> (like in DEP3) Debian,
> Upstream, Ubuntu, Whoever-else-uses-the-packaging.
>
> Opinions?

I like this idea.

There should be a Vcs-Debian-* too and used in most cases. A package
should use Vcs-Debian-* if the vcs is only used in Debian. A package
could use Vcs-* if the vcs is used in derived distros too.

What should we do if we have multiple upstream VCSes? For exapmle,
Eclipse has Eclipse and eclipse-build as upstream.

--
Benjamin Drung
Debian & Ubuntu Developer
 
Old 04-06-2011, 06:39 PM
Steve Langasek
 
Default More Vcs-Fields in debian/control?

On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote:
> > 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]

> > My suggestion would even go further (attention, I have NO idea how
> > debian/control is parsed and how much work the following would be):
> > Let's make that Vcs-<Vendor> with <Vendor> (like in DEP3) Debian,
> > Upstream, Ubuntu, Whoever-else-uses-the-packaging.

> I like this idea.

> There should be a Vcs-Debian-* too and used in most cases. A package
> should use Vcs-Debian-* if the vcs is only used in Debian. A package
> could use Vcs-* if the vcs is used in derived distros too.

What do you mean, "only used in Debian"? Do you expect Debian maintainers
to track whether or not downstreams have a separate VCS?

I don't think this is the right way to do it any more than we should rename
'Maintainer' to 'Maintainer-Debian'. If downstreams diverge, it should be
up to them to kee the information in debian/control current.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 04-06-2011, 06:55 PM
Benjamin Drung
 
Default More Vcs-Fields in debian/control?

Am Mittwoch, den 06.04.2011, 11:39 -0700 schrieb Steve Langasek:
> On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote:
> > > 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]
>
> > > My suggestion would even go further (attention, I have NO idea how
> > > debian/control is parsed and how much work the following would be):
> > > Let's make that Vcs-<Vendor> with <Vendor> (like in DEP3) Debian,
> > > Upstream, Ubuntu, Whoever-else-uses-the-packaging.
>
> > I like this idea.
>
> > There should be a Vcs-Debian-* too and used in most cases. A package
> > should use Vcs-Debian-* if the vcs is only used in Debian. A package
> > could use Vcs-* if the vcs is used in derived distros too.
>
> What do you mean, "only used in Debian"? Do you expect Debian maintainers
> to track whether or not downstreams have a separate VCS?

No. Simply answer the question: Is this VCS used by derived distros,
too? If not, it's Debian only. Two examples: The git repository for
apt-mirror is used only for Debian (there's only the master branch). The
git repository for vlc is used for Debian and Ubuntu (master branch for
Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu
natty, maverick branch for Ubuntu maverick, and so on).

> I don't think this is the right way to do it any more than we should rename
> 'Maintainer' to 'Maintainer-Debian'. If downstreams diverge, it should be
> up to them to kee the information in debian/control current.

--
Benjamin Drung
Debian & Ubuntu Developer
 
Old 04-06-2011, 10:10 PM
Jan Hauke Rahm
 
Default More Vcs-Fields in debian/control?

On Wed, Apr 06, 2011 at 08:55:05PM +0200, Benjamin Drung wrote:
> Am Mittwoch, den 06.04.2011, 11:39 -0700 schrieb Steve Langasek:
> > On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote:
> > > There should be a Vcs-Debian-* too and used in most cases. A package
> > > should use Vcs-Debian-* if the vcs is only used in Debian. A package
> > > could use Vcs-* if the vcs is used in derived distros too.
> >
> > What do you mean, "only used in Debian"? Do you expect Debian maintainers
> > to track whether or not downstreams have a separate VCS?
>
> No. Simply answer the question: Is this VCS used by derived distros,
> too? If not, it's Debian only. Two examples: The git repository for
> apt-mirror is used only for Debian (there's only the master branch). The
> git repository for vlc is used for Debian and Ubuntu (master branch for
> Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu
> natty, maverick branch for Ubuntu maverick, and so on).

And why would we care? We keep track of what we do. Anyone else may use
it or leave it. Let's please not invent another special case for Ubuntu
just because they're big or fancy[TM] at the moment. And no, I
definitely don't want VCS-derived-by-* for each and every derived distro
to make Ubuntu not so special-cased...

Hauke

--
.'`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de
: :' : Debian Developer www.debian.org
`. `'` Member of the Linux Foundation www.linux.com
`- Fellow of the Free Software Foundation Europe www.fsfe.org
 
Old 04-07-2011, 05:46 AM
Joey Hess
 
Default More Vcs-Fields in debian/control?

Evgeni Golov wrote:
> 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.

--
see shy jo
 
Old 04-07-2011, 05:53 AM
Russ Allbery
 
Default More Vcs-Fields in debian/control?

Joey Hess <joeyh@debian.org> writes:
> Evgeni Golov wrote:

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

While I agree with this, I think the problem that they're trying to solve
is getting the upstream revision history, not just a copy of the source.
The Debian repository may contain only snapshots of releases imported via
git-import-orig or the like, rather than the complete revision history.

Having the complete revision history is definitely nice, and I've started
doing that with a few upstreams that use Git, but it's a bit more
complicated to get the details sorted out. If upstream is using something
like Subversion or CVS, it's even more complicated, although there are
some Git tools that mostly work (at least for Subversion; CVS is another
matter). If upstream is using some other weird thing like bzr or
Mercurial or whatnot, we're now getting into rather more effort than I'd
personally want to bother with.

So I can still see the point of somewhere adding a pointer to the upstream
VCS repository.

However, is the control file really the right place for that? I guess we
don't have a better place right now, but this doesn't feel like package
metadata that needs to be put into the Sources file.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipuqd2to.fsf@windlord.stanford.edu">http://lists.debian.org/87ipuqd2to.fsf@windlord.stanford.edu
 
Old 04-07-2011, 06:22 AM
Raphael Hertzog
 
Default More Vcs-Fields in debian/control?

On Wed, 06 Apr 2011, Russ Allbery wrote:
> So I can still see the point of somewhere adding a pointer to the upstream
> VCS repository.
>
> However, is the control file really the right place for that? I guess we
> don't have a better place right now, but this doesn't feel like package
> metadata that needs to be put into the Sources file.

+1

And I'm not really keen on recognizing more Vcs-* fields in debian/control
as far as dpkg-dev is concerned.

There are lots of upstream-metadata that we might want to have available
and we need to find a proper solution that doesn't involve debian/control.

It should be outside of the package and probably shared accross
all Linux distributions. It seems to me to be a good extension of the work
done/planned on the cross-distribution app-store.

http://distributions.freedesktop.org/wiki/AppStream/Implementation

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110407062206.GC29377@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110407062206.GC29377@rivendell.home.ouaza.com
 
Old 04-07-2011, 06:33 AM
Ben Finney
 
Default 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
 
Old 04-07-2011, 06:36 AM
Ben Finney
 
Default More Vcs-Fields in debian/control?

Russ Allbery <rra@debian.org> writes:

> If upstream is using some other weird thing like bzr or Mercurial or
> whatnot, we're now getting into rather more effort than I'd personally
> want to bother with.

If Bazaar and Mercurial are “some other weird thing”, that doesn't bode
well for the future of the Debian tools interacting with VCSen. Is any
VCS other than Git to be deprecated?

--
“Unix is an operating system, OS/2 is half an operating system, |
` Windows is a shell, and DOS is a boot partition virus.” —Peter |
_o__) H. Coffin |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3kyftzo.fsf@benfinney.id.au">http://lists.debian.org/87d3kyftzo.fsf@benfinney.id.au
 

Thread Tools




All times are GMT. The time now is 01:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org