On 27 July 2017 at 09:13, R0b0t1 <r03...@gmail.com> 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.
Can you be more specific about the technologies you suggest and the exact problems you are trying to solve? Maybe you mean something like tarballs signed with GPG? Or SHA256 sums? In both cases there is still an issue with distributing signatures and the checksum files. I could upload a checksum file but since this would be in the same directory as the tarball and both could be manipulated by a potential attacker there seems little point. Ultimately you are able to (mostly) read the files in the source tarballs and audit for backdoors yourself (if this is your threat model). > 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 The repository exists to create the distributed source tarball itself. You need to read the documentation starting with release-guide.pod and understand it. This is really a prerequisite for any useful criticism of the build process. Yes it does look strange and needs improvement but there are reasons for it and most of it is written in easily understandable perl 5. > 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? Odd since there seemed to be enough words in your email! Really I don't have to justify anything to you but spreading knowledge of how this works is generally useful. The reason the released NQP package wasn't shipped was because there was a bug in the released one. This is documented in "lastmin-fixes.txt". This process isn't ideal as this file admits. This is only the second time the release tarballs weren't used. The NQP tarball you want is in the actual Rakudo Star tarball not the git repo for the build process. In hindsight I probably could have pointed it straight at a github versioned zip (although this would have added unzip as a dependency!) or just not bothered and shipped with a broken -ll-exception. > Are there any signed releases, or do I have to do the equivalent of curl|sudo? Extracting a tarball and manually running scripts isn't the same as running curl|sudo since you have the chance to read what the scripts do before running them. There is one subsystem where this isn't the case and its left as an exercise for the reader :-) > 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. The Rakudo Star system does use git submodules for the module dependencies. Maybe submodules in R* should be used for the Rakudo, NQP and MoarVM dependencies -- normally based on a tagged release but allowing a version a few commits later for bug fixes (which also should be tagged as .1). This isn't a bad idea. The problem with this is that the monthly Rakudo (not Star) tarballs still wouldn't get these fixes (and it's quite a lot of work for Rakudo upstream to produce potentially three extra tarballs for each patch) so most of the third party packaging (which doesn't tend to use Star) wouldn't get the fixes anyway. Still any extra tagging of bug fixes as .1 would help. I still think we need a -STABLE type branch as well. The whole rakudo (and star) build process doesn't fit in well with any third party systems (gentoo, cmake whatever). Having Perl 5 as a dependency for Perl 6 seems to be more reasonable than using anything else. It's open source and if you feel strongly enough about this to actually do the work you can fork the repo and make changes in your own branch. We would actively encourage contributions and it's easier to evaluate actual code changes than emailed suggestions. But be aware talk is cheap and code costs time. -- 4096R/EA75174B Steve Mynott <steve.myn...@gmail.com>
