Distros don't offer zef/Star/packaged modules

[rafaelschipiura]

I think they need to include at least zef and p6doc.

Many users will be trying to use Perl6 from distro packages, it's way easier to get a good experience if it's improved.

[AlexDaniel]

Is it expected for distros to include Star? Or should Star be a metapackage? In other words, what exactly do we want?

[rafaelschipiura]

I want zef and p6doc packaged.

[nxadm]

I don't see the point of Star in distributions. They will:

• offer way more modules than Star, as in not a selection but as many as they can package.
• have their own update schedule for the modules.
• have their own update schedule for Rakudo.

[rafaelschipiura]

Right, maybe not star, but the other two.

But we are talking about good newb experience, and finding star is a good thing, even if they don't really need it.

[nxadm]

@rafaelschipiura I keep a list of Rakudo on distros here: https://github.com/nxadm/rakudo-pkg#what-about-packages-provided-by-operating-systems

[rafaelschipiura]

@nxadm I'm using 2018.05 from Debian.

[robertlemmen]

regarding debian: this is very much work in progress, the current situation is certainly not what we are after in the long run. At the moment we really only have a "bare" perl6, no zef or any modules packaged. Work is progressing on that front, the next step is a change to the module and rakudo installation/removal scripts to manage precompiled files. After that the first modules can be packaged, which should of course include zef.

[niner]

On Donnerstag, 14. Juni 2018 00:21:01 CEST nxadm wrote:

I keep a list of Rakudo on distros here: https://github.com/nxadm/rakudo-pkg#what-about-packages-provided-by-operati ng-systems

The list is a bit incomplete. Rakudo, Inline::Perl5 and packages for cro and its dependencies are available for openSUSE Leap 42.2, 42.3, 15.0 and Tumbleweed: https://software.opensuse.org/package/rakudo Tumbleweed includes them in the default repository.

They are usually at most one release behind.

[MattOates]

So with Zef and Rakudo available and nothing else it used to be quite easy to bootstrap to having something like Star using Task::Star (https://github.com/tadzik/Task-Star). But this is no longer maintained /or/ part of the ecosystem. Perhaps the way Rakudo Star is actually built could be through a versioned meta package? That way the only thing that needs to be packaged is zef alongside the compiler. Personally I freaking hate how Perl 5 has all this hideous melange of OS level packages and then the inevitable CPAN packages. None of which necessarily work well together. The only real claim for why you'd want OS level are for things like libssl and other way more annoying builds where you want better OS compatibility.

[nxadm]

@niner

The list was intended to show the OS-supplied versions for the distributions that rakudo-pkg supports. And also which releases were OK to use. It may be a good idea to extend it and make it more generic.

There is PR now in the queue (@MasterDuke17 ++) for adding information for Arch. Maybe the information could be added for openSUSE tumbleweed as well (and Debian testing and unstable.

[nxadm]

@robertlemmen,

That is wonderful news. Your work is appreciated. I was under the impression that zef wouldn't be package and I am happy to hear this is the case when the problems you mentioned are solved.

[nxadm]

@MattOates

So with Zef and Rakudo available and nothing else it used to be quite easy to bootstrap to having something like Star using Task::Star (https://github.com/tadzik/Task-Star). But this is no longer maintained /or/ part of the ecosystem. Perhaps the way Rakudo Star is actually built could be through a versioned meta package? That way the only thing that needs to be packaged is zef alongside the compiler.

I don't see the use case for a Star metapackage in a distro because the modules are unrelated to a specific task. The idea of Star is to provide an easy way to get started with Rakudo. If the distribution does the packaging job, I don't see what it brings to the table than a collection of unrelated modules.

[rafaelschipiura]

@robertlemmen @MattOates Thanks guys for the wonderful job, really appreciated. I'm glad to know it will be solved soon.

@MattOates Many sysadmins won't bother to learn language-specific packaging. If it's not available in distro repos, it might as well not exist. But in this first moment Perl 6 is more for developers, so I agree it doesn't make sense to package modules for distros just yet.

[stmuk]

There are a number of issues mentioned here. Many of these have been discussed before without much agreement.

Generally distributions have had problems with packaging perl 6 in general (with a few exceptions like OpenSUSE, Debian etc.)

See https://perl6.org/downloads/others.html

I don't think this is the right place to discuss what distros should or shouldn't do. We should try and help them (maybe even join them) but its the responsibility of the distro maintainers to package. We are upstream.

To be frank I currently think any advice to use any packaged distro version of rakudo perl 6 is Bad Advice (unless perhaps for OpenSUSE). Perl 5 had a lot of problems with distro packaged versions and the Perl 6 situation is likely to be worse. The usual Perl 5 advice was to install in parallel with "system perl".

We release perl 6 monthly whereas the average lifespan of a distro perl 6 version is likely to be three years. Although 6.c is feature frozen there are a lot of bug fixes going in which will break code (as shown by toaster runs) and anyone using a version of perl 6 which is more than a few months old is likely to run into those problems. Neither can IRC really support random versions from many months ago and the usual response is going to be "upgrade maybe its fixed".

Until there is a more stable (in terms of changes) version of Perl 6 something like a Medium Term Support branch its going to be very hard to package anything useful.

[rafaelschipiura]

@stmuk All true, but it's also true the Perl 6 experience is harmed by that, so the bug should stay open until it's fixed.

People are working on it anyway.

[AlexDaniel]

@stmuk generally I agree, but here are some corrections:

Although 6.c is feature frozen there are a lot of bug fixes going in which will break code (as shown by toaster runs)

That's not exactly the case. Toaster shows regressions that we have to fix before the next release, so the failures that you'd typically see are non-existent on monthly releases. If the module actually relied on buggy or experimental behavior, a PR to this module is submitted with a backwards-compatible fix. I do agree that given the pace of rakudo development, there are many fixes coming in that can potentially break existing code, but you can't use toaster as an argument for that. Toaster is by definition a tool that allows us not to do such changes.

EDIT: OK I'll try to fix that before the next release: http://colabti.org/irclogger/irclogger_log/perl6-dev?date=2018-06-14#l178

Neither can IRC really support random versions from many months ago and the usual response is going to be "upgrade maybe its fixed"

Committable allows to run code on any revision (including monthly releases), so we don't have to recommend upgrading. But it's true that at this point in time the usual response actually works in many cases, yeah…

[robertlemmen]

to me it seems the perceived problems with distributions and perl packages fall into two categories:

• velocity. things in perl6 land move quickly, distributions will be slower. true, but that is a feature of a distribution, and is also true for many other pieces of software. slow/fast is quite subjective as well, I for example get annoyed if I have to upgrade an apache every 18 months ;) over time the feature velocity of perl6 will also converge, so it's not really a problem.

• quality. module packages are never up date or complete, and interactions between locally installed packages (e.g. through cpanm or zef or so) and distribution-provided packages is poor. this is primarily a function of the amount of work that goes into distro packages. the site/vendor mechanism that exists in perl6 will help with this. the tests that are part of regular perl 5/6 packages can also greatly help if they are used by the distribution in some sort of CI fashion to detect breakages introduced by new versions of packages.

so I personally think that distribution packaging of perl6 modules can work, and it would be fab if we succeed. but it's not going to be trivial and without work. I would also not be surprised if it will be a while until distro packages become preferred over direct installation.

One thing that is interesting in this regard is the granularity of packaging: in some ecosystems (e.g. node), packages tend to be infinitesimally small. that seems to be a deliberate decision and I can of course see good reasons for it. But at the same time such fine-grained packaging has tremendous problems, not only for distributions but also for humans that want to install packages. It seems that some middle ground in terms of package granularity would be an excellent thing to establish culturally...

[ugexe]

so the failures that you'd typically see are non-existent on monthly releases. If the module actually relied on buggy or experimental behavior, a PR to this module is submitted with a backwards-compatible fix.

This is only true for a new rakudo build only -- upgraded rakudos that have modules already installed are still busted after a breaking change. Many times those changes are worth some measure of breakage, but it should really be more of a "fix in ecosystem to seed users with fixed module as prereq to breaking changes" instead of "fix everything in the ecosystem before the next release breaks new installs".

[rafaelschipiura]

Not only new installs, sometimes existing installs will have Rakudo upgraded but not modules. Those would break.

Any breaking changes should wait for 6.d.

[AlexDaniel]

This is only true for a new rakudo build only -- upgraded rakudos that have modules already installed are still busted after a breaking change

That's a good point. That being said, I've looked through the list of PRs I did to modules during the last few months, and I'm fairly sure that this is not an issue in practice. For example, hash randomization and num precision fixes shouldn't brick installed modules. Even the upcoming change that turns the use of pack without experimental pragma into a compile-time error, only reveals modules that would probably fail during the run anyway (actually I just tested these modules and they're broken in other ways… I invite everyone to participate in 2018-08 ecosystem unbitrot SQUASHathon!).

So let's not blow things out of proportion. I've been putting consistent effort into making sure that we don't break modules willy-nilly (even when the module itself is in the wrong).

[rafaelschipiura]

Yes, that's true, but sometimes we do hear devs talking about it. Which does cause some concern, but we will keep it under perspective.