On 2023-07-15 16:06:56 +0200, Wojtek Kosior via wrote: > Hi Paul! > > > I'm not a computer scientist at all. At best you could call me a > > GNU/Linux end user for some time, but only to consume, never to > > produce. I would like to contribute a little, and for that I want to > > start with guix. > > That's cool! Please keep in mind, tho that Guix is not an "easy" distro > for novice users. Be ready to spend even more time learning stuff :) > > Having that said, the facilities Guix provides do allow for packages to > be created and maintained with relatively little time effort. I'm sure > learning will pay off! > > > I would like to package a program that I use on my computer but which > > is not in the repositories. It turns out to be a program written in > > Rust, with lots of dependencies. If I were to copy/paste all of what > > guix import -r returns the patch would be over 3000 lines long. > > > > I would like to know what are the best practices to adopt in this > > case. There are simple additions, updates, and additions with > > inheritance. I guess I shouldn't send a patch with all of this mixed > > up. > > I'm also a novice when it comes to sending to guix-patches but I > believe the perfect approach in this case would be to: > - add each package with a separate git commit > - make sure the final package builds and works properly on your PC > - create a patch series comprising all the additions with `git > format-patch` as described in the documentation > - describe in general what you did in series' cover letter that `git > format-patch` generated for you > - send the cover letter to guix-patches mailing list with `git > send-email` as described in the documentation; this will cause the > debbugs instance to open a new bug > - wait for an email response from debbugs with your new bug's number > - send the rest of your patch series with one invokation of `git > send-email --to=<BUG_NUMBER>@debbugs.gnu.org` as described in the > documentation > > This way the Guix committers will see all the package additions as > separate patches but grouped together in one debbugs issue. There's no > need to wait for one patch to be accepted before sending another in > this case. > > > Also, in this kind of case, I think that adding the program will take > > weeks when you're a beginner like me. Did I miss something? For > > example, is it possible to automate package inheritance during an > > update to a major version of a crate, or does it have to be done by > > hand? > > I'm not sure what you mean by this question. > > Anyway, you just touched one unfortunate truth — when you're a > beginner, any serious task can easily take weeks. > > My suggestion is that you start with something easier first. Perhaps an > application that only has 1 or 2 dependencies? > > > Last question, for my culture, is there a plan to "clean up" old > > packages and dependencies that are no longer used, or will the scm > > files grow indefinitely? > > There might be some misunderstanding here. Guix does allow > 1. for multiple versions of the same package to coexist > 2. and for multiple versions of the same package to share most of the > packaging code via inheritance. > However, the possibility 1. is only exercised for some strategic > packages like gcc. For casual packages, when upstream releases a new > version, some kind Guix contributor sends a patch that changes the > definition in the .scm file to now describe the new version. The old > version need not be explicitly deleted — its place is taken by the new > version :)
Is there a way to mark a package as a dependency? I can very well imagine that new version of some golang program would require less dependencies, but it is very easy to forget to remove the package definition. Is there a reasonable way to clean this up? > > Good luck and happy hacking ^^ > Wojtek W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature