starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #604] Please consider committing and publishing Cargo.lock #542

New issue

Closed

opened 2026-03-15 23:01:55 +03:00 by kerem · 15 comments

kerem commented

2026-03-15 23:01:55 +03:00

Owner

Originally created by @polyzen on GitHub (Nov 5, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/604

Is your feature request related to a problem? Please describe.
Reproducible builds.

error: the lock file needs to be updated but --locked was passed to prevent this

Originally created by @polyzen on GitHub (Nov 5, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/604 **Is your feature request related to a problem? Please describe.** Reproducible builds. `error: the lock file needs to be updated but --locked was passed to prevent this`

kerem

2026-03-15 23:01:55 +03:00

closed this issue
added the
crate:server
label

kerem commented

2026-03-15 23:02:11 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 6, 2018):

Originally we did include this, but it was removed in #458

There was discussion about this, but it might have happened outside the repo, possibly in users.rust-lang.org. Is this related to trying to build named? I've been wondering if we need to split named out of the trust-dns-server crate, although, given that this is all in a single project that might cause issues.

In what context is --locked being passed?

@bluejekyll commented on GitHub (Nov 6, 2018): Originally we did include this, but it was removed in #458 There was discussion about this, but it might have happened outside the repo, possibly in [users.rust-lang.org](https://users.rust-lang.org/). Is this related to trying to build `named`? I've been wondering if we need to split `named` out of the `trust-dns-server` crate, although, given that this is all in a single project that might cause issues. In what context is `--locked` being passed?

kerem commented

2026-03-15 23:02:16 +03:00

Author

Owner

@polyzen commented on GitHub (Nov 6, 2018):

Originally we did include this, but it was removed in #458

Yes, I understand (now) the FAQ states not to commit Cargo.lock for libraries, but seems that's controversial.

Also it appears you would need to use an "unstable" feature.

Is this related to trying to build named?

Yes.

In what context is --locked being passed?

Working towards reproducible builds for Arch Linux. BTW, is my package inappropriately named since it ships only named?

@polyzen commented on GitHub (Nov 6, 2018): > Originally we did include this, but it was removed in #458 Yes, I understand (now) the [FAQ](https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries) states not to commit `Cargo.lock` for libraries, but seems that's [controversial](https://github.com/raphlinus/pulldown-cmark/pull/152#issuecomment-436061992). Also it appears you would need to use an ["unstable" feature](https://github.com/rust-lang/cargo/issues/5654). > Is this related to trying to build named? Yes. > In what context is --locked being passed? Working towards reproducible builds for [Arch Linux](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=trust-dns-server). BTW, is my package inappropriately named since it ships only `named`?

kerem commented

2026-03-15 23:02:21 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 6, 2018):

I think this is work discussing how to best package this. I'm really quite unfamiliar with proper packaging in system distributions. I think naming the package trust-dns-server is fine, but my choice of named might become controversial, and we may want to change that.

I'm open to making changes to the structure of the crates and repo to support these distributions, although to be honest, I've planned to continue suggesting people just install directly from cargo. It looks like maybe that's exactly what your arch-linux install does, so that's probably fine. One comment I have, is there are a lot of compile time features that are defaulted to off, and some are experimental at the moment. Specifically, DNSSSEC is defaulted to off, yet it's in the description you have on the arch distribution, I'm not sure how we'd handle making it possible to enable those features.

I have done very little research in this area, so my answers here won't be great, and more likely I'll just keep asking questions ;)

@bluejekyll commented on GitHub (Nov 6, 2018): I think this is work discussing how to best package this. I'm really quite unfamiliar with proper packaging in system distributions. I think naming the package `trust-dns-server` is fine, but my choice of `named` might become controversial, and we may want to change that. I'm open to making changes to the structure of the crates and repo to support these distributions, although to be honest, I've planned to continue suggesting people just install directly from cargo. It looks like maybe that's exactly what your arch-linux install does, so that's probably fine. One comment I have, is there are a lot of compile time features that are defaulted to off, and some are experimental at the moment. Specifically, DNSSSEC is defaulted to off, yet it's in the description you have on the arch distribution, I'm not sure how we'd handle making it possible to enable those features. I have done very little research in this area, so my answers here won't be great, and more likely I'll just keep asking questions ;)

kerem commented

2026-03-15 23:02:26 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 6, 2018):

Yes, I understand (now) the FAQ states not to commit Cargo.lock for libraries, but seems that's controversial.

I remember getting a lot of feedback on this, but of course I can't find it now. It was a lot harder to maintain the dependencies under this model, and created downstream issues for (library) users, as I remember it.

@bluejekyll commented on GitHub (Nov 6, 2018): > Yes, I understand (now) the FAQ states not to commit Cargo.lock for libraries, but seems that's controversial. I remember getting a lot of feedback on this, but of course I can't find it now. It was a lot harder to maintain the dependencies under this model, and created downstream issues for (library) users, as I remember it.

kerem commented

2026-03-15 23:02:31 +03:00

Author

Owner

@polyzen commented on GitHub (Nov 6, 2018):

I'm open to making changes to the structure of the crates and repo to support these distributions

I remember getting a lot of feedback on this, but of course I can't find it now. It was a lot harder to maintain the dependencies under this model, and created downstream issues for (library) users, as I remember it.

If named were to be split out into its own crate, the lock file could then be published for that binary crate. There is code (IIUC) to prevent lock files being published otherwise. The lock files would then also be available for the libraries' developers.

Specifically, DNSSSEC is defaulted to off, yet it's in the description you have on the arch distribution,

Will fix that.

I'm not sure how we'd handle making it possible to enable those features.

No worries here, as we're meant to ship packages as vanilla as possible.

@polyzen commented on GitHub (Nov 6, 2018): > I'm open to making changes to the structure of the crates and repo to support these distributions > I remember getting a lot of feedback on this, but of course I can't find it now. It was a lot harder to maintain the dependencies under this model, and created downstream issues for (library) users, as I remember it. If `named` were to be split out into its own crate, the lock file could then be published for that binary crate. There is code (IIUC) to prevent lock files being published otherwise. The lock files would then also be available for the libraries' developers. > Specifically, DNSSSEC is defaulted to off, yet it's in the description you have on the arch distribution, Will fix that. > I'm not sure how we'd handle making it possible to enable those features. No worries here, as we're meant to ship packages as vanilla as possible.

kerem commented

2026-03-15 23:02:36 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 7, 2018):

There is code (IIUC) to prevent lock files being published otherwise.

Do you mean in cargo publish?

The lock files would then also be available for the libraries' developers.

Sorry, by library I think you're referring to the general trust-dns software, not specifically the trust-dns-server library, right?

I think the concern I have right now is that with the current project construction, the lock file would be stored in the root, effecting all the crates, and not just the binary. So we'd need to exclude it from the published artifacts to crates.io for the other crates (something we probably need to slim down anyway). That would be a path forward.

@bluejekyll commented on GitHub (Nov 7, 2018): > There is code (IIUC) to prevent lock files being published otherwise. Do you mean in `cargo publish`? > The lock files would then also be available for the libraries' developers. Sorry, by library I think you're referring to the general trust-dns software, not specifically the trust-dns-server library, right? I think the concern I have right now is that with the current project construction, the lock file would be stored in the root, effecting all the crates, and not just the binary. So we'd need to exclude it from the published artifacts to crates.io for the other crates (something we probably need to slim down anyway). That would be a path forward.

kerem commented

2026-03-15 23:02:41 +03:00

Author

Owner

@polyzen commented on GitHub (Nov 7, 2018):

Do you mean in cargo publish?

https://github.com/rust-lang/cargo/blob/0.31.0/src/cargo/sources/path.rs#L346-L349

Sorry, by library I think you're referring to the general trust-dns software, not specifically the trust-dns-server library, right?

I think the concern I have right now is that with the current project construction, the lock file would be stored in the root, effecting all the crates, and not just the binary. So we'd need to exclude it from the published artifacts to crates.io for the other crates (something we probably need to slim down anyway). That would be a path forward.

Yes, and thank you for the consideration!

@polyzen commented on GitHub (Nov 7, 2018): > Do you mean in `cargo publish`? https://github.com/rust-lang/cargo/blob/0.31.0/src/cargo/sources/path.rs#L346-L349 > Sorry, by library I think you're referring to the general trust-dns software, not specifically the trust-dns-server library, right? > > I think the concern I have right now is that with the current project construction, the lock file would be stored in the root, effecting all the crates, and not just the binary. So we'd need to exclude it from the published artifacts to crates.io for the other crates (something we probably need to slim down anyway). That would be a path forward. Yes, and thank you for the consideration!

kerem commented

2026-03-15 23:02:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 7, 2018):

Ah, so published crates never included the lock file, or at least not for the last few years.

But that raises a different question, if it's not published with the crate on crates.io, it won't be available for your installation (from crates.io) in arch, will it? Or am I missing something.

@bluejekyll commented on GitHub (Nov 7, 2018): Ah, so published crates never included the lock file, or at least not for the last few years. But that raises a different question, if it's not published with the crate on crates.io, it won't be available for your installation (from crates.io) in arch, will it? Or am I missing something.

kerem commented

2026-03-15 23:02:52 +03:00

Author

Owner

@polyzen commented on GitHub (Nov 7, 2018):

Also it appears you would need to use an "unstable" feature.

Mentioned it in passing ^

@polyzen commented on GitHub (Nov 7, 2018): > Also it appears you would need to use an ["unstable" feature](https://github.com/rust-lang/cargo/issues/5654). Mentioned it in passing ^

kerem commented

2026-03-15 23:02:57 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 7, 2018):

I see. That connects all the dots for me, thanks.

I think the best path forward will be to put the binaries into separate crates. Does this block your path forward? or is this an optimization/stabilization for the arch installation script?

@bluejekyll commented on GitHub (Nov 7, 2018): I see. That connects all the dots for me, thanks. I think the best path forward will be to put the binaries into separate crates. Does this block your path forward? or is this an optimization/stabilization for the arch installation script?

kerem commented

2026-03-15 23:03:02 +03:00

Author

Owner

@polyzen commented on GitHub (Nov 7, 2018):

Great. :) This would be an optimization/stabilization, yes. Reproducible builds are still an ongoing process at Arch:
https://tests.reproducible-builds.org/archlinux/archlinux.html

@polyzen commented on GitHub (Nov 7, 2018): Great. :) This would be an optimization/stabilization, yes. Reproducible builds are still an ongoing process at Arch: https://tests.reproducible-builds.org/archlinux/archlinux.html

kerem commented

2026-03-15 23:03:07 +03:00

Author

Owner

@polyzen commented on GitHub (Jan 19, 2019):

Note: Publishing the lockfile with the server crate is not done yet. Will file an issue or PR once publish-lockfile is stabilized.

@polyzen commented on GitHub (Jan 19, 2019): Note: [Publishing the lockfile](https://github.com/rust-lang/cargo/issues/5654) with the server crate is not done yet. Will file an issue or PR once `publish-lockfile` is stabilized.

kerem commented

2026-03-15 23:03:12 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 19, 2019):

Oh. Silly me. I didn’t confirm. We can add it to the crate manually in Cargo.toml, no?

@bluejekyll commented on GitHub (Jan 19, 2019): Oh. Silly me. I didn’t confirm. We can add it to the crate manually in Cargo.toml, no?

kerem commented

2026-03-15 23:03:17 +03:00

Author

Owner

@polyzen commented on GitHub (Jan 19, 2019):

I don't know, but I have a feeling https://github.com/rust-lang/cargo/blob/0.32.0/src/cargo/sources/path.rs#L347-L350 would make it not possible.

@polyzen commented on GitHub (Jan 19, 2019): I don't know, but I have a feeling https://github.com/rust-lang/cargo/blob/0.32.0/src/cargo/sources/path.rs#L347-L350 would make it not possible. See also https://github.com/sharkdp/diskus/pull/17.

kerem commented

2026-03-15 23:03:22 +03:00

Author

Owner

@polyzen commented on GitHub (Jun 3, 2019):

Cargo will be changed to always include Cargo.lock in the .crate file if the package has binaries or examples.

@polyzen commented on GitHub (Jun 3, 2019): > [Cargo will be changed to always include Cargo.lock in the .crate file if the package has binaries or examples.](https://github.com/rust-lang/cargo/issues/5654#issuecomment-497863987)

kerem referenced this issue

2026-03-16 02:10:01 +03:00

[PR #542] [MERGED] decrease MAX_TTL to one day #1502