[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: Re: [Nix-dev] Proposal: adding fetchapt support to nixpkgs
From: Roger Qiu <roger.qiu () matrix ! ai>
Date: 2016-11-12 10:16:02
Message-ID: CA+HLvX=YwHoP1Bq+4FKMjcc8edexBe8zGg3pVu-kxfd+wHBycQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I think what we need is a bot that will autosubmit PRs to bump new versions
by tracking some commonly updated widely used applications like chromium.
This shouldn't be too difficult.
On 11/11/2016 11:34 PM, "Profpatsch" <mail@profpatsch.de> wrote:
> On 16-10-25 04:42am, Chuan-kai Lin wrote:
> > Adding support for fetching binary packages in Debian format from an APT
> > repository would solve this problem. I envision that a nixpkg would
> > specify:
> > - the APT repository base URL
> > - the release name (e.g., stable, testing, or unstable),
> > - the binary package name,
> > - repository signing key (for repositories that implement secure APT,
> > https://wiki.debian.org/SecureApt).
> >
> > And the fetchapt derivation would:
> > - Fetch Release and Release.gpg files from the repository
> > - Verify digital signature
> > - Fetch Packages file
> > - Check hash value of Packages file against the hash value listed in
> > Release file
> > - Extract binary package path that correspond to the given package name
> > from Packages file
> > - Fetch the binary package
> > - Check hash value of binary package against the hash value listed in
> > Packages file
>
> That doesn't work, and it's by design.
> In order for nix (the package manager) to be able to install something,
> it needs to know the input files *beforehand*, by hash. So nix **cannot**
> evaluate a derivation where the source hash changes.
>
> The one thing that could be done is completely automating the
> version-bumping process, that is write a program that follows debian
> releases, bumps the hashes, tests the functionality of the resulting
> executables (!!) and then commits the new version to nixpkgs.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it's urgent, call me.
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
[Attachment #5 (text/html)]
<p dir="ltr">I think what we need is a bot that will autosubmit PRs to bump new \
versions by tracking some commonly updated widely used applications like chromium. \
This shouldn't be too difficult.</p> <div class="gmail_quote">On 11/11/2016 11:34 \
PM, "Profpatsch" <<a \
href="mailto:mail@profpatsch.de">mail@profpatsch.de</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 16-10-25 04:42am, Chuan-kai Lin \
wrote:<br> > Adding support for fetching binary packages in Debian format from an \
APT<br> > repository would solve this problem. I envision that a nixpkg \
would<br> > specify:<br>
> - the APT repository base URL<br>
> - the release name (e.g., stable, testing, or unstable),<br>
> - the binary package name,<br>
> - repository signing key (for repositories that implement secure APT,<br>
> <a href="https://wiki.debian.org/SecureApt" rel="noreferrer" \
target="_blank">https://wiki.debian.org/<wbr>SecureApt</a>).<br> ><br>
> And the fetchapt derivation would:<br>
> - Fetch Release and Release.gpg files from the repository<br>
> - Verify digital signature<br>
> - Fetch Packages file<br>
> - Check hash value of Packages file against the hash value listed in<br>
> Release file<br>
> - Extract binary package path that correspond to the given package name<br>
> from Packages file<br>
> - Fetch the binary package<br>
> - Check hash value of binary package against the hash value listed in<br>
> Packages file<br>
<br>
That doesn't work, and it's by design.<br>
In order for nix (the package manager) to be able to install something,<br>
it needs to know the input files *beforehand*, by hash. So nix **cannot**<br>
evaluate a derivation where the source hash changes.<br>
<br>
The one thing that could be done is completely automating the<br>
version-bumping process, that is write a program that follows debian<br>
releases, bumps the hashes, tests the functionality of the resulting<br>
executables (!!) and then commits the new version to nixpkgs.<br>
<br>
--<br>
Proudly written in Mutt with Vim on NixOS.<br>
Q: Why is this email five sentences or less?<br>
A: <a href="http://five.sentenc.es" rel="noreferrer" \
target="_blank">http://five.sentenc.es</a><br> May take up to five days to read your \
message. If it's urgent, call me.<br> \
______________________________<wbr>_________________<br> nix-dev mailing list<br>
<a href="mailto:nix-dev@lists.science.uu.nl">nix-dev@lists.science.uu.nl</a><br>
<a href="http://lists.science.uu.nl/mailman/listinfo/nix-dev" rel="noreferrer" \
target="_blank">http://lists.science.uu.nl/<wbr>mailman/listinfo/nix-dev</a><br> \
</blockquote></div>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic