Skip to content

Allow published repo to reside on different filesystem#510

Closed
l1k wants to merge 1 commit intoaptly-dev:masterfrom
l1k:master
Closed

Allow published repo to reside on different filesystem#510
l1k wants to merge 1 commit intoaptly-dev:masterfrom
l1k:master

Conversation

@l1k
Copy link

@l1k l1k commented Mar 22, 2017

Requirements

All new code should be covered with tests, documentation should be updated. CI should pass.

Description of the Change

Currently packages are hardlinked from the internal pool to the published repo, which requires them to reside on the same filesystem. This precludes mounting the published repo from a remote machine, e.g. via NFS or sshfs, which would be desirable to physically separate the machine hosting the internal pool and signing key from the machine serving the published repo.

Autodetect such a setup and, if found, copy files instead of using hardlinks.

Add helpers to check whether two given paths reside on the same filesystem and to check whether an already published package file is identical to the one to be published by comparing their MD5 hashes.

Checklist

  • unit-test added (if change is algorithm)
  • functional test added/updated (if change is functional)
  • man page updated (if applicable)
  • bash completion updated (if applicable)
  • documentation updated
  • author name in AUTHORS

@smira
Copy link
Contributor

smira commented Mar 23, 2017

Thanks for the contribution, it seems to be somewhat close to #519, I thought if we could do the same trick here by opening up local filesystem publish roots?

I can work on the PR to provide that, and we can add option to copy files/symlink them after that?

Currently packages are hardlinked from the internal pool to the
published repo, which requires them to reside on the same filesystem.
This precludes mounting the published repo from a remote machine,
e.g. via NFS or sshfs, which would be desirable to physically separate
the machine hosting the internal pool and signing key from the machine
serving the published repo.

Autodetect such a setup and, if found, copy files instead of using
hardlinks.

Add helpers to check whether two given paths reside on the same
filesystem and to check whether an already published package file
is identical to the one to be published by comparing their MD5 hashes.
@l1k
Copy link
Author

l1k commented Mar 24, 2017

Okay, I'll wait for @seeraven to update his pull, then rebase. Or perhaps his pull will already include the copy functionality.

@seeraven feel free to ping me if you need help/testing/reviewing.

Meanwhile, I've rebased on current master and all tests fail because of a golint warning which is a false positive: "hardlinked" is a misspelling of "hardline" (misspell) Perhaps misspellings can be demoted from hard errors to noncritical warnings? Thanks!

@seeraven
Copy link
Contributor

I've just created a new pull request https://github.com/smira/aptly/pull/521 with a new approach to specify one or multiple local endpoints with a customizable link method (hardlink, symlink or copy). Let me know if this works for you.

@l1k
Copy link
Author

l1k commented Apr 13, 2017

Closing in favor of #521.

@l1k l1k closed this Apr 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants