RE: Root partition and usrland on one slice, /usr/local ports and

[Cy Schubert]

Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

---
Sent using a tiny phone keyboard. Apologies for any typos and autocorrect.

Cy Schubert
<Cy.Sc...@cschubert.com> or <c...@freebsd.org>

-----Original Message-----
From: Eugene Grosbein
Sent: 11/11/2017 12:37
To: lankfor...@charter.net; 'freebsd...@freebsd.org'
Subject: Re: Root partition and usrland on one slice, /usr/local ports and srcon another

12.11.2017 1:39, lankfor...@charter.net wrote:

> It's been quite a while since I've tried a rebuild, but I think the
> problems appeared early when gcc and gas and dependencies were being
> built. I tried just symlinks, then different settings of the build
> variables, and (IIRC) enabling clang. Perhaps I could start fresh with
> 11.1, but then perhaps placing everything on one slice is the most
> straightforward solution.

I still don't get what specific problems did you have
but I'm sure they were not due to symlinking as such links work just fine
for me with gcc, and with clang too.



_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Jamie Landeg-Jones]

Cy Schubert <Cy.Sc...@komquats.com> wrote:

> Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

I encountered a problem a few years ago with ports, when WRKDIRPREFIX was set, and there was a symbolic link in the destination. It didn't happen for every port, but I tracked the culprit down to one of the /usr/ports/Mk scripts. It's at this point I switched to nullfs instead.

I can't remember any more details on it, and the problem may not even occur anymore

[Jamie Landeg-Jones]

Eugene Grosbein wrote:

> I still don't get what specific problems did you have
> but I'm sure they were not due to symlinking as such links work just fine
> for me with gcc, and with clang too.

Cy Schubert <Cy.Sc...@komquats.com> replied:

> Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.

I just came across one with multimedia/ffmpeg4:

Debugging the install stage gives this, though the cpio error messages are sent to null by default:

| + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
| + /usr/bin/cpio -dumpl /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/Changelog
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/CREDITS
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/INSTALL.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/LICENSE.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/MAINTAINERS
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/README.md
| cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/RELEASE_NOTES
| 0 blocks
| + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES '(' -type d -exec /bin/sh -xc 'cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg && chmod 755 "$@"' . {} + -o -type f -exec /bin/sh -xc 'cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg && chmod 0644 "$@"' . {} + ')'
| + cd /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
| + chmod 0644 Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
| chmod: Changelog: No such file or directory
| chmod: CREDITS: No such file or directory
| chmod: INSTALL.md: No such file or directory
| chmod: LICENSE.md: No such file or directory
| chmod: MAINTAINERS: No such file or directory
| chmod: README.md: No such file or directory
| chmod: RELEASE_NOTES: No such file or directory

cheers, Jamie

[Eugene Grosbein]

15.06.2018 23:14, Jamie Landeg-Jones wrote:

>> I still don't get what specific problems did you have
>> but I'm sure they were not due to symlinking as such links work just fine
>> for me with gcc, and with clang too.
>
> Cy Schubert <Cy.Sc...@komquats.com> replied:
>
>> Neither do I. I've been using a combination of symlinks, ufs, nullfs, zfs legacy and straight zfs in various configurations over the years on various systems with no problems whatsoever.
>
> I just came across one with multimedia/ffmpeg4:
>
> Debugging the install stage gives this, though the cpio error messages are sent to null by default:
>
> | + /usr/bin/find -Ed Changelog CREDITS INSTALL.md LICENSE.md MAINTAINERS README.md RELEASE_NOTES
> | + /usr/bin/cpio -dumpl /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg
> | cpio: Cannot extract through symlink /scratch/root/ports_base/usr/ports/multimedia/ffmpeg/work/stage/usr/local/share/doc/ffmpeg/Changelog

Well, I known this. Some time ago our cpio got "broken" in a way:
it now demands "--insecure" option to work with symlinks same way it worked long before without this option.

While I may understand motivation, this change still broke previously working scripts
like /usr/src/tools/tools/nanobsd/nanobsd.sh (generates NanoBSD images)
using cpio without "--insecure" when some parts of the building system are symlinked to other locations.