Sentry dsym support

[zancarius]

Ahti333 posted a question regarding Sentry's dsym support on the AUR repo for this package, and I'd like to honor the request. I'm currently looking at drafting a split PKGBUILD that would either 1) produce two copies of Sentry, one with dsym and one without (I don't like this option), or 2) produce a copy of Sentry plus an additional package containing symsynd and its dependencies which would be installed in Sentry's local site-packages.

The latter should be possible, but it will require extra vigilance when Sentry updates because of the extra work required in copying these dependencies into a separate site-packages as it'll have to be verified manually. If these dependencies were to change, those changes will have to be reflected in the package split. Though this isn't ideal, the alternative (generating Sentry twice) is worse, would double the build time, and potentially create some confusion.

Unfortunately, supporting dsym will require a build time dependency on LLVM (via makedepends) for Sentry. I hope this won't interfere with the build processes some users have for building Sentry, hence why I'm posting this issue.

In particular, I'd like input from @codekoala, @mastacheata, and @mitchhentges. I hope they won't mind being pinged on this matter, because I welcome their past contributions to the Sentry PKGBUILD and I feel their opinions would be valuable. I also hope an additional build time dependency won't interfere with their Sentry deployment processes.

[mitchhentges]

TBH, my Sentry server is mostly a hobby server for fun projects, so it isn't too bad if there's deployment issues, or an extra dependency.

The try-hard part of me doesn't feel too comfortable with adding an extra dependency, even for installations that don't need it. At the same time, managing two different Sentry packages appears to be a far bigger evil, and installing LLVM is really not a big deal. So, I'd opt towards option 2) Sentry with an additional package.

Thanks a bunch for supporting this package btw. It's pretty awesome :tada:

[zancarius]

Thanks for weighing in on this, @mitchhentges! I'm not terribly thrilled at adding LLVM either, but there is some solace in the fact that it's only for the build dependencies and dsym package (base Sentry won't require it to be installed). Unfortunately, if you only build Sentry (and not dsym), there's no way to override makedepends without editing the PKGBUILD by hand every time. I believe makepkg may let you choose which to build.

It's a bit of a dilemma, but I can understand why dsym support is desirable: Sentry is useless as a debug/logging host without it for certain platforms (iOS in the case of the individual requesting the change) and probably others.

On the other hand, if you're unable to build Sentry on a separate install from the host and don't want to pollute your installed packages with unnecessary ones, you can always build them in an nspawn container. I've had to do this with firefox-kde-opensuse when I actually used it for its KDE integration, although that's because it wouldn't build otherwise.

Come to think of it, I'm actually not sure if one of the dependent libraries, symsynd, will build without LLVM installed. Briefly looking at the source suggests it may use some LLVM headers. If it were only a runtime dependency, that'd be great, but I doubt it. Oh well.

[codekoala]

Personally, I have no beef with the additional build-time dependency on llvm, but that's probably because other things I rely on also use llvm :)

Here's a (probably too dirty) proposal: add the additional dependency to makedepends inside the package or build function for the dsym package?

[zancarius]

Same here, @codekoala. My dev machine has so much junk on it (is it junk if it's useful?).

I was hoping to isolate makedepends such that it's only needed for dsym, but you can't do that if you're using split packages being as it appears makedepends is global for the PKGBUILD. It's kind of a bummer since I'd rather not maintain two packages that do essentially the same thing, and a split package is ideal for something like this. Unfortunately, I can't see any way around it. I think you're right, though. It's not really a big deal, and maybe I'm bikeshedding a bit over a relatively modest dependency that will probably be installed on most dev machines anyway.

I'll be testing from an nspawn container later to see if symsynd will build without LLVM. I don't think it will, but that'll give us an extra data point. I'm mostly hoping to avoid breaking anything important for everyone since I already have a pretty bad history of doing that as it is. ;)

Thanks a ton!

[codekoala]

Ah man, I thought I had modified the makedepends in split packages before. I'm probably getting it confused with regular dependencies.

Good luck with the nspawn container. That sounds really fun :)

[zancarius]

I thought as much too when I modified php56 from the AUR some time ago. Apparently I hadn't, and the docs say otherwise. I think I understand the Arch devs' design choice on this matter, because a forum thread lead me to a discussion about how nested depends=() in split packages aren't verified before build which probably indicates why makedepends is global.

Offtopic:

nspawn containers are fun, especially for spinning up dev instances, but they're probably not as useful as Docker containers since they're still a bit new and they're essentially a whole system image (LXC-like). You can also run them unprivileged, providing some degree of isolation, but it's not a security feature and I don't mean to convey it as such. I'm hoping it'll mature a bit more, because it's quite handy. I even have a systemd-based Gentoo image running on my Arch install via systemd-nspawn (OpenRC works, too, but requires some effort and will break integration with systemd).

Perhaps we should include some instructions in the PKGBUILD comments for people who want to avoid polluting their main install with unnecessary packages by building using arch-nspawn or just point a link to the dev wiki. Probably the latter since it's a bit out of scope from what the PKGBUILD intends...

[zancarius]

Some extra data: Looks like symsynd requires clang and llvm-libs to build.

Any disputes with including these dependencies? (clang pulls in llvm-libs.)

[codekoala]

None from me :) On May 25, 2016 12:37 PM, "Benjamin A. Shelton" notifications@github.com wrote:

Some extra data: Looks like symsynd requires clang and llvm-libs to build.

Any disputes with including these dependencies? (clang pulls in llvm-libs.)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/zancarius/archlinux-pkgbuilds/issues/7#issuecomment-221666594

[mitchhentges]

None from me either!

[zancarius]

If anyone's especially brave, here's the dsym change. You'll need the supporting files, of course (sentry.install, .service), but I *think this should do it.

It's a bit ugly since there's a bit of manual copying involved. I have no means of testing dsym support, though.

[mastacheata]

Nice to include me, but I've got only very little experience with either arch Packages or c-Compilers. I've studied computer science, but you barely learn anything about compilers there and my professional experience is pretty much focused on web development so I've got little to no contact points with debug symbols either.

In general though, library/dependency "clutter" and filesize don't really matter where I deploy arch linux at the moment. (At least not in the area of a few 100 mb)

[zancarius]

Thanks for the response, @mastacheata! I've tried to ping everyone who has contributed previously to improving this PKGBUILD because I wanted to avoid surprising those of you who have helped me out.

If the build-time dependencies aren't that big a deal (~100-130MiB; no increase if you're just installing Sentry without dsym), then I might push this out once we get a response from the user asking for this change and it seems the split package fulfills their use case better than maintaining local changes for their own purposes.

I do mostly web services as well (usually Python, some Golang), so debug symbols in Sentry aren't immediately useful to me either, but I can see where support for it would be a huge benefit for developing on a platform like iOS or anything using clang/LLVM and friends. It looks like it was a fairly recent addition to Sentry, too (probably sometime during the 8.x branch).

Thanks again for your input, everyone!

[ahti]

Thanks for getting to this so quickly, all!

I installed your updated PKGBUILD and symbolication works, but only after I changed both .service files to not change $PATH. When symbolicating, sentry will look for llvm-symbolizer at runtime and that failed, because /usr/bin was not in the path.

I don't know wether this would break any other functionality of sentry that might rely on the executables of it's pip dependencies or similar, but have also not found a way to append to $PATH inside the .service file. I guess hardcoding /opt/sentry/bin:/usr/bin would work (unless llvm-symbolizer moves somewhere else at some point).

(I also didn't try to build in a clean container yet.)

[zancarius]

Actually, I don't think the $PATH envvar needs to be in there and may be a hold over from a much earlier version (and virtualenv should override everything where appropriate; Sentry shouldn't be running anything from the virtualenv bin dir). Good catch!

I hope you don't mind being a test subject. If not, could you try the PKGBUILD from this commit plus the supporting unit files?

[ahti]

Yup, that one works great 👍

[zancarius]

Sweet. If sentry-dsym support works, I'll go ahead and push this to the AUR if there's no objections.

[zancarius]

All right, it's on the AUR. If these changes cause any regressions, feel free to re-open this issue, create a new issue, or post on the AUR comments.

Thanks a ton everyone!