Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza

Submitted by Raphael Hertzog on Tue, 03/02/2010 - 03:06

Debian Development

Hi,

On Wed, 11 Nov 2009, Stefano Zacchiroli wrote:
> It would be nice to have support for a Description field in the source
> stanza of debian/control.
>
> My rationale for that is manyfold:
>
> 0) (Starting intuition) most source package have a description per se,
> intuitively, that is the same description you'd find on the upstream
> homepage that made you download a specific software. Sure different
> binary packages can have different specific purpose, but it is in
> most cases possible to have a single all-encompassing description.

Should that description be exported in the .dsc then ?

[ Skipping tools that would benefit from the information ]

> 2) A frequent pattern in debian/control is as follows:
>
> Package: a
> Description: a is foo bar ...
> Project src is .... (COMMON TEXT)
> .
> In this package you find a
>
> Package: b
> Description: b is baz quux ...
> Project src is .... (COMMON TEXT)
> .
> In this package you find b
>
> Source descriptions can be used to factoring out COMMON TEXT in a
> single place.
>
>
> I'm reporting this bug report against dpkg-dev because, AFAICT, it would
> be simply possible to implement this wishlist as an expansion done by
> dpkg-gencontrol at the end of the build. The expansion would simply copy
> the COMMON TEXT from the source package description (if any) at the
> beginning of each binary package description (possibly adding a
> paragraph separator "\n.\n"). I've no idea if such a naive
> implementation would have drawbacks elsewhere.

If I do something like that it's rather with substvars. You could use
${source:Description:body} and ${source:Description:title} in the binary
package description to refer to the the corresponding parts of the source
description.

> What is the stance of dpkg-dev maintainers on this?

I think it's ok. But some more feedback would be welcome, CCing -devel for
this.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20100302100514.GB6516@rivendell

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Ben Finney on Tue, 03/02/2010 - 16:21.

Raphael Hertzog writes:

> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the
> binary package description to refer to the the corresponding parts of
> the source description.

Sounds great, with the minor caveat that I'd rather not have the vars
using different terms from what is already used to describe those
fields. Instead, (bikeshed mode activate) I'd prefer
‘${source:Description:synopsis}’ and ‘${source:Description:full}’.

--
\ “Read not to contradict and confute, nor to believe and take |
`\ for granted … but to weigh and consider.” —Francis Bacon |
_o__) |
Ben Finney

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Christian Perrier on Wed, 03/03/2010 - 00:13.

Quoting Ben Finney (ben+debian@benfinney.id.au):

> Sounds great, with the minor caveat that I'd rather not have the vars
> using different terms from what is already used to describe those
> fields. Instead, (bikeshed mode activate) I'd prefer
> ‘${source:Description:synopsis}’ and ‘${source:Description:full}’.

agreed, too. We use "synopsis" in most of our documentations and this
is also how we refer to it in dle reviews.....

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Russ Allbery on Tue, 03/02/2010 - 14:43.

Raphael Hertzog writes:

> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the binary
> package description to refer to the the corresponding parts of the
> source description.

That sounds like a great idea to me.

--
Russ Allbery (rra@debian.org)

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Josselin Mouette on Tue, 03/02/2010 - 05:45.

Le mardi 02 mars 2010 à 11:05 +0100, Raphael Hertzog a écrit :
> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the binary
> package description to refer to the the corresponding parts of the source
> description.

I think I like the idea. I often found myself repeating the first
paragraph of the long description in each binary package, so this would
help reduce duplication and avoid such things to get out-of-sync.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Michael Biebl on Tue, 03/02/2010 - 15:13.

On 02.03.2010 13:38, Josselin Mouette wrote:
> Le mardi 02 mars 2010 à 11:05 +0100, Raphael Hertzog a écrit :
>> If I do something like that it's rather with substvars. You could use
>> ${source:Description:body} and ${source:Description:title} in the binary
>> package description to refer to the the corresponding parts of the source
>> description.
>
> I think I like the idea. I often found myself repeating the first
> paragraph of the long description in each binary package, so this would
> help reduce duplication and avoid such things to get out-of-sync.

I agree. I looked over my packages and noticed, that for most of them, the
package description has a generic part (the source:Description part if you will)
and a binary package specific part.

So, Raphael's idea sounds like an improvement I'd happily use.

Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Stefano Zacchiroli on Tue, 03/02/2010 - 05:45.

On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> The substvars approach sounds good to me. I think I'd use it quite a lot,
> specially in libraries.

That, however, does not solve the problem of how to access a source
package description from infrastructure tools such as DDPO, the PTS,
etc. More generally, it does not solve the problem of where to tag that
information as such: you would just solve the problem of "description
factorization" across multiple binary packages.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Raphael Hertzog on Tue, 03/02/2010 - 06:19.

On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
> On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> > The substvars approach sounds good to me. I think I'd use it quite a lot,
> > specially in libraries.
>
> That, however, does not solve the problem of how to access a source
> package description from infrastructure tools such as DDPO, the PTS,
> etc.

The sensible answer is putting this information in the .dsc and thus in
the Sources files. But it means that the file would get somewhat bigger
and it might meant again supplementary changes in the infrastructutre if
people want to see those descriptions translated (but I'm not convinced
we need translations on Sources, users of those are mostly developers
contrary to Packages).

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Loïc Minier on Wed, 03/03/2010 - 08:14.

On Tue, Mar 02, 2010, Raphael Hertzog wrote:
> The sensible answer is putting this information in the .dsc and thus in
> the Sources files. But it means that the file would get somewhat bigger
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

While that seems sensible, I wonder whether it would make sense to
include the information in Packages.gz instead. There's a high level
use case which is not too nicely covered at the moment: if one upgrades
with a graphical package management tools displaying progress of the
upgrade, it would typically show which package is being upgraded with
its description, but you typically upgrade all binary packages from the
same source at the same time, so in the list of packages to update,
you'd likely see "The GTK+ graphical user interface library"
(libgtk2.0-0), "The programs for the GTK+ graphical user interface
library" (libgtk2.0-bin), "Common files for the GTK+ graphical user
interface library" (libgtk2.0-common) while it would probably make
sense to only offer a single entry for the software bundle being
updated, i.e. for all binary packages provided by the same source, with
a nice description.

Now that use case still has a flaw in usability in that even per source
package descriptions wouldn't mean much to non-developers, so it's
probably a minor improvement in package managers not worth the effort
of changing infrastucture etc.

--
Loïc Minier

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Charles Plessy on Wed, 03/03/2010 - 02:47.

Hello everybody,

Le Tue, Mar 02, 2010 at 02:04:56PM +0100, Raphael Hertzog a écrit :
> On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
> > On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
> > > The substvars approach sounds good to me. I think I'd use it quite a lot,
> > > specially in libraries.
> >
> > That, however, does not solve the problem of how to access a source
> > package description from infrastructure tools such as DDPO, the PTS,
> > etc.

Moreover, debhelper does not check debian/substvars (at least it did not a
couple of monthes ago), but debian/.substvars, so the
source description would have to be in an unexpected place (or a bug should be
reported on debhelper).

> The sensible answer is putting this information in the .dsc and thus in
> the Sources files. But it means that the file would get somewhat bigger
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

In the long term, we could aim at separating the dpkg meta-data, like the
Source, Package, Architecture, Depends, etc. fields, from the archive
meta-data, like the Vcs-*, DM-Upload-Allowed, Section, Priority, etc. fields.
All the Debian system is aptable anyway, so the Description could be also be
considered archive meta-data without information loss. Unfortunately, this is
perhaps inconvenient for third-party packages.

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Christian Perrier on Wed, 03/03/2010 - 00:13.

Quoting Raphael Hertzog (hertzog@debian.org):

> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

Those source packages descriptions would indeed be, most of the time,
the boilerplate that's being put (and often repeated) in each and
every binary package produced by the source package.

This approach with a common boilerplate that's a description of the
source package and a few specific paragraphs for each binary package,
is promoted through the reviews of descriptions done in
debian-l10n-english.

It does not increase the burden on translators....it even reduces it
quite often as DDTP translation is based on paragraphs.

In general, I like this proposal and I think we could quite highly
benefit from it. The idea of using substvars to be able to repeat the
source package description and use it as a boilerplate is particularly interesting.

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Jean-Christophe... on Tue, 03/02/2010 - 06:43.

On 02/03/2010 14:04, Raphael Hertzog wrote:
> On Tue, 02 Mar 2010, Stefano Zacchiroli wrote:
>> On Tue, Mar 02, 2010 at 01:03:57PM +0100, Emilio Pozuelo Monfort wrote:
>>> The substvars approach sounds good to me. I think I'd use it quite a
lot,
>>> specially in libraries.
>>
>> That, however, does not solve the problem of how to access a source
>> package description from infrastructure tools such as DDPO, the PTS,
>> etc.
>
> The sensible answer is putting this information in the .dsc and thus in
> the Sources files. But it means that the file would get somewhat bigger
> and it might meant again supplementary changes in the infrastructutre if
> people want to see those descriptions translated (but I'm not convinced
> we need translations on Sources, users of those are mostly developers
> contrary to Packages).

Moreover, if the Sources descriptions are essentially the same as the
descriptions of binary packages, the translation effort would not be
that great (essentially, splitting the current binary descriptions).

I agree that it entails some infrastructure adaptations, and that
putting it in .dsc is the way to go. I am no DD, anyway.

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Stefano Zacchiroli on Tue, 03/02/2010 - 05:16.

On Tue, Mar 02, 2010 at 11:05:14AM +0100, Raphael Hertzog wrote:
> > 0) (Starting intuition) most source package have a description per se,
> > intuitively, that is the same description you'd find on the upstream
> > homepage that made you download a specific software. Sure different
> > binary packages can have different specific purpose, but it is in
> > most cases possible to have a single all-encompassing description.
>
> Should that description be exported in the .dsc then ?

It is not clear to me what would be the pro/cons of having the
description there, so I cannot tell. However, if the rationale of the
current information in .dsc is currently "all source package information
are there", then yes, it would make sense (even though I don't care that
much).

> [ Skipping tools that would benefit from the information ]

Fair enough. Still, for the others interesting to comment on this
wishlist bug report, please check the original bug report to know which
tools and infrastructure parts would benefit. It is quite a relevant set
of tools.

> > 2) A frequent pattern in debian/control is as follows:

> If I do something like that it's rather with substvars. You could use
> ${source:Description:body} and ${source:Description:title} in the binary
> package description to refer to the the corresponding parts of the source
> description.

That it *can* be currently implemented using substvars is clear. As
usual however, there is a trade-off between expressivity of the current
tool set (i.e. it can be done) and convenience (i.e. how easy it is). I
believe currently no one is doing that, but I'm also convinced that if
supported out of the box it will become a quite handy feature to reduce
information duplication and be kind with various parts of our toolchain.

> I think it's ok. But some more feedback would be welcome, CCing -devel
> for this.

Thanks for the feedback and for the initiative.

Cheers.

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Submitted by Goswin von Brederlow on Wed, 03/03/2010 - 03:34.

Stefano Zacchiroli writes:

> On Tue, Mar 02, 2010 at 11:05:14AM +0100, Raphael Hertzog wrote:
>> > 0) (Starting intuition) most source package have a description per se,
>> > intuitively, that is the same description you'd find on the upstream
>> > homepage that made you download a specific software. Sure different
>> > binary packages can have different specific purpose, but it is in
>> > most cases possible to have a single all-encompassing description.
>>
>> Should that description be exported in the .dsc then ?
>
> It is not clear to me what would be the pro/cons of having the
> description there, so I cannot tell. However, if the rationale of the
> current information in .dsc is currently "all source package information
> are there", then yes, it would make sense (even though I don't care that
> much).

I think there are 2 things here:

1) Add a description to *.dsc

This would be just for packages.d.o or apt-cache showsrc. Buildd admins
could find it also usefull so they can quickly see what a package is
about without first having to lookup what binary packages a source
builds.

2) Factoring out a common paragraph from binary descriptions

If I understood this right the source description would be put into
substvars automatically and the binary description can then reuse that
variable.

This would make many control files smaller and avoid duplication of
text. Chaning the common text would only need a change at one place
then.

I think both things are a good idea.

>> [ Skipping tools that would benefit from the information ]
>
> Fair enough. Still, for the others interesting to comment on this
> wishlist bug report, please check the original bug report to know which
> tools and infrastructure parts would benefit. It is quite a relevant set
> of tools.
>
>> > 2) A frequent pattern in debian/control is as follows:
>
>> If I do something like that it's rather with substvars. You could use
>> ${source:Description:body} and ${source:Description:title} in the binary
>> package description to refer to the the corresponding parts of the source
>> description.
>
> That it *can* be currently implemented using substvars is clear. As
> usual however, there is a trade-off between expressivity of the current
> tool set (i.e. it can be done) and convenience (i.e. how easy it is). I
> believe currently no one is doing that, but I'm also convinced that if
> supported out of the box it will become a quite handy feature to reduce
> information duplication and be kind with various parts of our toolchain.

But currently one would have to manually set the substvar and the text
it is set too would come from somewhere unintuitive. By having dpkg set
the substvar from the source description and ha ving this properly
documented it would make it obvious where the text comes from and allow
for easy translation.

Using a substvar gives the maintainer the flexibility to decide which
binary packages should have the common stanza included and which don't.
E.g. you could have 2 packages with the stanza and a third with a
completly different description.

>> I think it's ok. But some more feedback would be welcome, CCing -devel
>> for this.
>
> Thanks for the feedback and for the initiative.
>
> Cheers.

MfG
Goswin

acetylcholine.com

Who's online

Navigation

User login

Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

Bug#555743: dpkg-gencontrol: add support for Description:-s in t

New forum topics

Recent comments