The details of how to use the star GitHub repository are in tools/star/release_guide.pod .
You're entirely welcome to create a bundling that has a better build system than what Rakudo Star uses -- indeed, Rakudo Star has always been intended to be just one of many possible bundlings of Rakudo and useful modules. Even if you just create a repo to demonstrate a better way of organizing modules, that'd be helpful. The earliest versions of the Rakudo Star build system started out by trying to use Git submodules to manage packages, but it quickly proved to be unwieldy and almost impossible to understand and maintain. Perhaps the submodule ecosystem has changed since then, though. Pm On Thu, Jul 27, 2017 at 03:13:19AM -0500, R0b0t1 wrote: > Are there any releases signed by the developers? The official releases > located at https://rakudo.perl6.org/downloads/star/ do not seem to > have signatures available. > > As a stopgap measure I attempted to clone > https://github.com/rakudo/star and run Configure.pl. I felt it strange > that it warned me against using the code in the repository as cloned > from the repository (why does the repository exist?) but continued > with --force, only to find out that some of the folders in the > directory structure need to be initialized. A mailing list posting was > found detailing how to continue > (http://www.nntp.perl.org/group/perl.perl6.compiler/2013/05/msg8915.html) > and the steps were followed. Unfortunately, the nqp package download > failed with error 404, which made me see the following command was > part of the preparation script: > > >wget --no-check-certificate > >https://rakudo.perl6.org/downloads/nqp/nqp-2017.07-9-gc0abee7.tar.gz -O > >src/nqp-2017.07-9-gc0abee7.tar.gz > > I have no words. Can anyone justify this choice? > > Are there any signed releases, or do I have to do the equivalent of curl|sudo? > > > What is being done should actually be done with Git submodules, or the > more recent feature, subtrees. There is no reason for the releases to > be prepared in this way. What has been created is a very inflexible > package management system. If what you want is a package management > system, then I would suggest adapting Gentoo's portage to the > project's needs, as KDE seems to have done with their Craft build > system. However what the project needs is version control that will > handle dependencies. > > Git's submodules fit perfectly because they pin a directory to a > branch which is exactly what is being done here, but it is integrated > with Git and can use existing authentication and verification > mechanisms (HTTPS, SSH, GPG). There are various articles which try to > paint submodules as unsuitable for most uses but I hope it is easy to > see that what they do is exactly what is desired in this instance. > > If submodules do not seem suitable, there are subtrees, but these blur > the lines between projects. That might be okay, but they are slightly > more complicated to use. > > R0b0t1.
