Front page | perl.perl5.porters |
Postings from September 2014
Re: metaconfig source control/distribution and Debian's DFSG
From: H.Merijn Brand
September 26, 2014 06:35
Re: metaconfig source control/distribution and Debian's DFSG
Message ID: email@example.com
On Thu, 25 Sep 2014 21:07:59 -0400, Andy Dougherty
> 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
> > since the preferred form of modification of Configure is not provided.
> > You can see the bug report at .
> I'd quibble with that -- though I am no longer the primary Configure
I am now
> I actually did prefer most users to directly modify Configure.
So do I
> 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"
The main problem with generating Configure from meta is not the
availability of the metaunits used for perl, but the way meta/dist has
to be installed to make them work the way it does.
As Andy already stated, it proves to be much easier to "backport" the
direct patches to Configure and friends to meta than it is to instruct
(new) users to patch metaunits the way it should. Even seasoned users
seem to have problems doing so. I had two sessions past year explaining
the ways and woes of how it works, sincerely hoping to get fresh blood
into the configuration process. The bus factor currently is about 1½
If I stop maintaining perl, only Andy understands the *complete*
process right now, and Jarkko would be able to (reluctantly) step in.
(Andy still understands some of the steps way better than I do). I did
try to improve the docs, and I also made the meta/dist *as I use it*
available on my CPAN, but it still is so much different a process from
the rest of perl5 core development that it does not attrackt (new)
people to join in: it is not a focus area that attracks youngsters, as
NO END USER will see what your work involves, while when you improve
the regular expression engine, the whole of the perl user community
> > I was able to mostly replicate Configure by following the procedure at
> > , 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.
As the current maint for this process, I communicate with the
maintainer of dist/meta on a rather regular basis. I give feedback of
what we changed, and I look at the changes he makes to see if those
will be usable for perl.
As part of the metaunits is still used from dist, part is a set of
(slightly) modified units from dist, and part is the units written only
for perl, keeping those in sync is a hell of a job. On simply cannot
stay in sync 100%
> 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.
Even if you rsync from one system to another and use exactly the same
tools, the order can change based on locale setting :(
> 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.
If possible, modify the hint files instead.
> 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.
One extra note here: the generation process decides what units to
include based on the references used in the perl source tree. This
means that not all units will be used. Including all units in a
distribution might lead to extra confusion.
> 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
"likely"? /me laughs out loud
> 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
I'd rather put my free time in trying to get closer to dist-4.0 than we
are now (3.5+) than modifying the current process to enable
distribution of something that would work for all users that are
unlikely to use it anyway
> Anyway, that's my off-the-top-of-my head reaction.
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.19 porting perl5 on HP-UX, AIX, and openSUSE