Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixpkgs doc: add and clean some paragraphs #16579

Closed
wants to merge 1 commit into from

Conversation

joelmo
Copy link
Contributor

@joelmo joelmo commented Jun 28, 2016

Motivation for this change
Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

The quickstart chapter is renamed to packaging guide. Paragraphs
regarding same topic in the guide and chapter about submitting changes
have been rewritten. A new section about poilicies have been added. Both
chapters are now indented.

@ericsagnes
Copy link
Contributor

There are a few typos: comparasion -> comparison, availible -> available, diffrent -> different.
You could use a spell checker to have all the typos fixed.

@joelmo
Copy link
Contributor Author

joelmo commented Jun 29, 2016

Thanks for pointing at these, I had them corrected.


<para>The nixpkgs package repository is not restrictive in
comparison to other distributions. Non free packages are allowed but
will not be built by Hydra. Packaging binaries is allowed, patching
Copy link
Member

@FRidh FRidh Jul 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first sentence in this paragraph I would drop since it doesn't add anything really.

Next, you will have to make a clearer distinction between free and non-free software. Indeed, we package non-free software and then we typically need to patch the binaries.

In the case of free software it is different. Here we want all software to be build from source. There are cases that we do use binaries, but those are, at least how I see it, exceptions, and they are typically only included because of, say, a complex build procedure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I made a edit according to your suggestions. Could you also review that?

The quickstart chapter is renamed to packaging guide. Paragraphs
regarding same topic in the guide and chapter about submitting changes
have been rewritten. Some bullet points was collapsed into paragraphs. A
new section about poilicies have been added. Both chapters are now
indented. One reference to the mailing list have been in-lined.
@joachifm
Copy link
Contributor

joachifm commented Jul 3, 2016

Would it be possible to leave the guidelines out of this for now? To me, these guidelines are not that helpful in the common case.

@joelmo
Copy link
Contributor Author

joelmo commented Jul 3, 2016

@joachifm do you mean leave out the policy section and the first paragraph I added to the quick-start guide? About the policy section I think it is useful to get an idea of what can be accepted in nixpkgs so I don't see why this cannot be included. I think everyone should be able to know this before starting a package.

@joachifm
Copy link
Contributor

joachifm commented Jul 3, 2016

What I mean is to propose the guidelines in a separate PR. I don't think everybody will realize that what appears to be mainly a cleanup PR also codifies repo wide policies.

binary cache.

For example: <command>nixos-version</command> returns
<command>15.05.git.0998212 (Dingo)</command>. So you can do:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about:

For example: <command>nixos-version --hash</command> returns <literal>d7450443c42228832c68fba203a7c15cfcfb264e</literal>. So you can do:

@joelmo joelmo closed this Dec 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants