develooper Front page | perl.perl5.porters | Postings from December 2021

Re: What should go in dist/ and cpan/

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
December 24, 2021 07:57
Subject:
Re: What should go in dist/ and cpan/
Message ID:
YcV9QjZtCbx3vaO+@etla.org
On Thu, Dec 23, 2021 at 10:25:25PM +0100, Leon Timmermans wrote:
> I can't help noticing that for many distributions it's rather unintuitive
> what its upstream will be. I have the general impression that it's often a
> matter of "it was orphaned, so we adopted it" more than anything else. I
> don't think that state is desirable.
> 
> I would propose that we would aim to split them on a simple question "will
> most changes come from inside or outside of core". That would mean that
> e.g. Devel::PPPort would stay dist/, but something like FindBin should move
> to cpan/. That doesn't mean we should move all those things right away,
> often we should find a reliable maintainer first.

This *seems* to be what we *say* we already do. From perlhack.pod:

    =head2 Patching a core module
    
    This works just like patching anything else, with one extra
    consideration.
    
    Modules in the F<cpan/> directory of the source tree are maintained
    outside of the Perl core.  When the author updates the module, the
    updates are simply copied into the core.  See that module's
    documentation or its listing on L<https://metacpan.org/> for more
    information on reporting bugs and submitting patches.
    
    In most cases, patches to modules in F<cpan/> should be sent upstream
    and should not be applied to the Perl core individually.  If a patch to
    a file in F<cpan/> absolutely cannot wait for the fix to be made
    upstream, released to CPAN and copied to blead, you must add (or
    update) a C<CUSTOMIZED> entry in the F<"Porting/Maintainers.pl"> file
    to flag that a local modification has been made.  See
    F<"Porting/Maintainers.pl"> for more details.
    
    In contrast, modules in the F<dist/> directory are maintained in the
    core.


ie

dist: we can patch it directly in blead

cpan: we should send patches upstream



And making this distinction easy to see was (also) important, which was why
we made the split like this.

I wouldn't want to get rid of that - if we re-arrange things so that we
have a directory where *some* subdirectories "shouldn't be patches" and
some should, that is also hard to follow.


Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
cpan/

We could split dist and go 4 ways:

ext:
     unchanged. core-only

bundle:
    what was cpan/

dist:
    upstream blead, dual life

cpan:
    blead can patch if needed



I think that this layout would address both concerns.


Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About