Re: Proposing a new Perl Module Versioning Scheme

[Dan Book]

I wrote a blog post thoroughly explaining Perl module versions and agree
with the assessment and suggested method presented (though I have no
comment on the remedy).

http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html

-Dan


On Thu, Aug 6, 2020, 1:09 PM Tina Müller  wrote:

> Hi,
>
> I'm working at SUSE, and for about a year I have been in charge of updating
> the CPAN modules in SUSE Open Build Service:
> https://build.opensuse.org/project/show/devel:languages:perl
>
> This is half automated. The spec file is generated with the cpanspec
> script,
> and we manually look over the diff and then request the package to be
> updated.
>
> I would like to make a suggestion and will explain the problems in detail,
> so
> that we are all on the same page.
>
> # Status Quo
>
> As you probably know, the versioning scheme of Perl modules differs from
> rpm.
> For perl, the versions are decimal, so it can happen that for a given
> module A
> versions 0.23 and 0.3 are released. The latter one is higher for perl.
> Semantically, 0.23 is 0.230.0 and 0.3 is 0.300.0, when correctly
> translated to a
> rpm like version.
>
> You can also use versions like 1.2.3 in perl. In that case, they are
> already
> semantically equal to rpm like versions. The majority of perl modules
> still uses
> decimal versions, though.
>
> Many distributions including openSUSE and Fedora are just taking over the
> perl
> module version literally.
>
> This sometimes leads to problems, for example if module B requires module
> A:
>
>  Requires: perl(A) >= 0.23
>
> When module A is uploaded with version 0.3, this will result in an
> unresolvable
> dependency.
>
> In those cases we have to manually fix the requirement.
> Granted, this doesn't happen very often, but when, it's annoying.
>
> There might also be cases where it is the other way around, e.g. module A
> has versions 0.02 and 0.1. 0.02 is just the same as 0.2 in rpm.
>
> Module B has:
>
>  Requires: perl(A) >= 0.1
>
> If module A is still at version 0.02, the dependency will be satisfied,
> because 0.1 is lower in rpm than 0.02.
> But that is wrong. In this case we don't see the mistake though.
>
> Here is a discussion about this that started when I posted my Howto
> for creating a CPAN module with correct Metadata:
> https://github.com/perlpunk/perl5-module-meta/issues/5
>
> # Alternative
>
> The correct way to translate the versions for the spec would be:
>
>  perl -wE'say version->parse($ARGV[0])->normal;' 0.23
>  v0.230.0
>
> and then we just have to cut off the 'v' at the beginning.
> This should work correctly for all module versions, and it is the right
> thing
> to do.
> We wouldn't need any manual handling anymore.
>
> # Problem
>
> As it is impossible to just change all modules in the distributions at the
> same
> time, we need backwards compatibility.
>
> # Proposal
>
> I discussed this on IRC #opensuse-factory. A suggestion came up how to
> avoid
> having to be backward compatible.
>
> The versions of each module inside a CPAN distribution are usually
> generated
> at build time with perl.prov
> (
> https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.prov
> ).
>
> Some distributions also use
> https://github.com/rpm-software-management/rpm/blob/master/scripts/perl.req
> but openSUSE doesn't. The dependencies are extracted at the time when the
> spec
> file is generated.
>
> We could add a new capability additionally to perl(). Maybe cpan(). This
> can
> use the new versioning scheme.
> The packages could be built with both capabilities.
> As soon as all packages are rebuilt, we can start to adjust the Requires
> lines to use the new capability.
>
> This part is actually pretty easy and shouldn't require much work. Please
> correct me if I'm wrong.
>
> However, there is also the package version, and instead of
>
>  Require: perl(A::B) >= x.y
>
> one can do
>
>  Require: perl-A-B >= x.y
>
> so for those package versions we need backward compatibility.
>
> My idea is to take a snapshot of all CPAN modules we have in our repository
> and save the package id and the version.
>
> The migration strategy to the new versioning scheme would be:
>
> All modulues having 1, 2 or 3 decimals can update to the new scheme
> whenever
> a new version is uploaded.
>
> Let's take module A as the example again. The current (CPAN) version would
> be
> 0.23.
>
> When a new version 0.3 is uploaded, we compare the version for A to our
> saved
> version 0.23. If it is (decimally) higher, we use the new scheme: 0.300.0.
> Same thing for other modules requiring A (although we mostly use capability
> requirements anyway).
>
> For all modules having 4 or more decimals, the switch to the version scheme
> has to wait until the major version is updated (which might be never for
> some
> modules).
> E.g. module B has 1.201703. Then we have to wait until the major version is
> incremented to 2.
>
> I made some statistics for our 

Re: Making Perl site paths ABI-specific

[Dan Book]

On Thu, Apr 25, 2019 at 3:36 PM Petr Pisar  wrote:

>
> Any opinions? Should we go with this change? Wich format do you like most?
>

I think this is a great idea, and the first option is most similar to
normal Perl lib paths.

-Dan
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: CPAN Search Going Away

[Dan Book]

On Thu, May 24, 2018 at 1:03 PM, Petr Šabata  wrote:
>
>
> Do we know if files like /modules/02packages.details.txt are
> still going to be provided by cpan.org?  If not, virtually all
> CPAN tools will have to be updated.  cpanspec included.
>

Yes. That file is on all CPAN mirrors which will not be changed. These are
CPAN mirrors: https://www.cpan.org https://cpan.metacpan.org
http://search.cpan.org/CPAN/ (last one should be changed to another mirror)

-Dan
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QUD3Z4LZOBGI5WMEBSDOHQ6BXAEROWBX/

Re: CPAN Search Going Away

[Dan Book]

On Thu, May 24, 2018 at 12:34 PM, Petr Pisar  wrote:

> On Fri, May 18, 2018 at 10:55:02AM +0100, Dave Cross wrote:
> > See https://log.perl.org/2018/05/goodbye-search-dot-cpan-dot-org.html
> >
> > This means that the URLs included in RPMs of CPAN modules will need to
> > change to MetaCPAN URLs.
> >
> > Please let me know if I can be any help making this happen.
> >
> I can mass update spec files for all Perl packages. I submitted this
> Fedora 29
> change request  MetaCPAN>
> and this packaging guidelines request
> .
>
> If it is approved, I will try to do that before Perl 5.28 mass rebuild so
> that the change becomes visible in Fedora 29 release.
>
> I propose rewriting both URL and Source tags like this:
>
> -URL:http://search.cpan.org/dist/CPANPLUS/
> +URL:https://metacpan.org/release/CPANPLUS
> -Source0:http://www.cpan.org/authors/id/B/BI/BINGOS/CPANPLUS-%{
> cpan_version}.tar.gz
> +Source0:https://cpan.metacpan.org/authors/id/B/BI/BINGOS/
> CPANPLUS-%{cpan_version}.tar.gz
>
> Are you fine with it?
>
> While the old addresses will probably work, I believe it makes sense to
> update
> them because:
>
> (1) The less intermediary steps to the final location, the better. (Fewer
> things can get broken.)
> (2) It's good when a user see the same address in RPM and in his web
> browser.


The changes look good to me. However, the source URL does not really need
to be updated (it will still mirror the file); www.cpan.org is not
changing, only search.cpan.org is. If there is any source URL using the
search.cpan.org mirror that could be updated:
http://search.cpan.org/CPAN/authors/id/... ->
https://www.cpan.org/authors/id/... or
https://cpan.metacpan.org/authors/id/...

-Dan
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/K2ACTGGZUAJZQHXFO43UO6FQZP3ITRWB/

Re: Installing all core Perl modules by perl package

[Dan Book]

On Wed, Jun 14, 2017 at 7:52 AM, Petr Pisar  wrote:
>
> Therefore I offered them that Fedora can make "dnf install perl" working as
> thay want and it will be implemented by renaming perl-core to perl and
> giving a new name to present perl package.
>
> Thus I created this Fedora Change
>  Install_Core_Modules>
> naively aiming to Fedora 27.
>
> My plan is to move files form perl subpackage to a new perl-interpreter
> subpackage and rename perl-core to perl.
>

As a Fedora user and one of the mentioned #perl people, this is a fantastic
solution, thank you. I also agree that the modular packages need to stay as
they are, there is no good reason to change that aspect.

-Dan
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Perl on Reddit

[Dan Book]

Sorry I don't have quotes but I was not subscribed to the list yet.

Looking at the dependency chain for perl-core, it brings in perl-devel
directly and as a prerequisite for modules such as perl-ExtUtils-MakeMaker
and perl-ExtUtils-Miniperl. Assuming perl-devel is what brings in the C
development toolchain that's undesired, would this be a possibility,
however distant (direction suggested by hobbs on IRC): remove the
perl-devel dependency from these modules, and have 'perl' then be able to
install everything else - the whole set of expected core modules?

Side tangent, but Perl 6 is its own future, it has only the same relevance
to the future of Perl 5 as Python and Ruby do.

-Dan
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org