develooper Front page | perl.perl5.porters | Postings from September 2014

Re: metaconfig source control/distribution and Debian's DFSG

Thread Previous | Thread Next
Andy Dougherty
September 26, 2014 01:08
Re: metaconfig source control/distribution and Debian's DFSG
Message ID:
On Thu, Sep 25, 2014 at 10:16:32PM +0100, Dominic Hargreaves wrote:
> Hi,
> The Debian project has recently received a bug report indicating that
> the perl source package we distribute does not comply the the DFSG[1]
> since the preferred form of modification of Configure is not provided.
> You can see the bug report at [2].

I'd quibble with that -- though I am no longer the primary Configure
maintainer, I actually did prefer most users to directly modify Configure.
It ended up being much easier than supporting users using metaconfig to
generate Configure.  Users are of course welcome to fetch and install
metaconfig and use it, but I wouldn't say that was the "preferred"

> I was able to mostly replicate Configure by following the procedure at
> [3], but it took some googling to find that, so it's not obvious
> (and even if it was, we're not shipping the contents of that repository
> with perl, so we still fall foul of the basic principle).

As far as I am concerned, you certainly are welcome to ship the
contents of that repository with Debian, but that alone won't be

> Could someone fill me in on why the metaconfig units are not part of
> the main perl source tree? It'd be much more convenient if they were
> part of the perl source (and there were clear instructions for using
> them included).

I think it's mainly because it would be a lot of work for very little
gain.  Let me explain the process a little bit more:

Generating Configure requires both the 'dist' package (which contains
metaconfig) and the perl-specific metaconfig units.  Historically, we have
often ended up using a patched 'dist', or a version that lagged behind
the main package.  We definitely can't simply assume the version in the
Debian archive will work.  Generating Configure also sometimes involves
patching or fixing the output of metaconfig in various ways.  All the
information to do this should be in perl's metaconfig git repository.

It is also sometimes difficult to check or merge the generated output.
The metaconfig units are assembled in order based on dependencies,
but those dependencies don't fully constrain the order.  The result is
that the order of units can vary depending on who generates Configure.
Thus even a tiny patch to a single metaconfig unit can result in a
Configure patch with hundreds of lines that are just shuffling
parts around.

That's another reason why modifying the metaconfig units is not
necessarily the "preferred" form of modification of Configure.

Obviously, it's all a bit involved, and a fair amount of effort to
figure out.

The way it's set up now, we encourage people to simply patch Configure.
If someone wants to go the metaconfig route instead, it's a lot of
extra work, but presumably the person deliberately chooses that route
knowing it's extra work.  If we include all the units in the source tree
instead, I think end users will have an expectation of greater support.
They will expect it to work, and work easily, right out of the box.
Getting it to that point will require significant effort, and I really
don't see the benefit.  Of course, if someone else wants to do it and
support it, that's fine with me.

> If we have to, we can make a tarball of that repository and include
> it with the perl source package, but it seems like it would we should
> explore the possibility of fixing this discrepancy upstream, rather
> than working around it in Debian. In fact, it's likely we'd also have
> to supply the patches between the current metaconfig output and what's
> actually in the perl release tarball, since Configure is explicitly
> allowed to be patched even though it's generated.

To be complete, you would have to include both perl's metaconfig
repository and an appropriately patched 'dist' source tree, which would
likely differ somewhat from Debian's existing 'dist' tree.  If the
intent is to actually use it, there are probably a bunch of installation
issues to work out.  If you want to check your results, you'll have to
confront the reshuffling problem.

> Any thoughts about the best way of making this cleaner, or why we
> shouldn't?

Short summary:  I think it would be a lot of work for very little

Anyway, that's my off-the-top-of-my head reaction.

    Andy Dougherty

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About