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

Re: Computing Build-Depends at build time (and other updates to debian/control)?

On Tue, Aug 23, 2016 at 08:04:02AM +0100, Neil Williams wrote:
> On Tue, 23 Aug 2016 00:56:14 -0400
> Josh Triplett <josh@joshtriplett.org> wrote:
> > Paul Wise wrote:
> > > This would be incredibly useful for moving towards a world of
> > > automatic packaging based on whatever metadata upstream is already
> Just because something useful exists within a particular collection does
> not mean that the entire collection deserves to be in Debian. We've had
> this discussion before about packaging all of CPAN automatically or all
> of pypi automatically or all of whatever other virtual-packaged site is
> the current flavour.

I wouldn't suggest packaging the entirety of any such archive (or, at
least, not uploading all such packages to Debian), but I'd want to
upload all the library packages needed as build dependencies of a
program written in that language.

> Automated packaging is approximately equivalent to some of the lowest
> quality packaging I've seen.

Depends heavily on the quality of the automation and the metadata it
works from.  Automation produces consistency, and allows fixing any
issues in the automation tool rather than in a pile of packages.

> Keeping the packaging manual makes it less likely that even more
> rubbish will end up in the archive.

Whether the dependency generation occurs when generating the source
package or at build time, the packaging will *definitely* involve as
much automation as possible.

> > > providing for other package management formats.
> > >
> > > https://summit.debconf.org/debconf14/meeting/25/debdry-debian-dont-repeat-yourself/
> > > http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debdry_Debian_Dont_Repeat_Yourself.webm
> > > https://wiki.debian.org/AutomaticPackagingTools  
> > 
> > That describes the exact case that motivated me to raise this; the
> > uniform upstream packaging metadata used throughout the entire Cargo
> > ecosystem contains all the information needed to generate
> > Build-Depends (and Depends) on all other necessary Cargo packages.
> > I'd like to avoid repeating that information.
> It may look like that at the moment - as soon as those dependencies
> start getting complex (typically, as soon as something in the chain
> depends on something which is *not* part of the special clique or not
> written in that particular language) then it all falls over in a heap.

I very specifically limited my statement to "all the information needed
to generate Build-Depends (and Depends) on all other necessary Cargo
packages".  Any other dependencies would indeed require manual
additions, at least until the upstream metadata starts handling that.

Seems easy enough to accept a minimal control template to augment the
generated one.

- Josh Triplett

Reply to: