I'm sure there are a few precedents; there's a history of software which needs fixing before it can work properly in a distribution environment where everything is coordinated to work together. Some of this is as simple as conflicting executable names, one of which gets renamed to something which doesn't conflict. From your description it doesn't appear that your case is all that different.

Basically you are going to have to either work things out so that everything can share one lldb, or rename your special copies of things (lldb-swift, etc.) or install them outside of the usual paths. (Sometimes things go into a subdirectory of /lib64, for example.)

Of course dnf would not allow you to even install a package which overwrites a file already installed by another package, so there's no chance of overwriting things. But you're going to have to work things out so that everything can be installed in parallel. How you go about doing that is probably not something we're going to be able to tell you.

So, theoretically, the Swift binaries could go into /usr/bin, but the special Swift-lldb, and accompanying libraries and such, theoretically could go into /usr/lib64/swift?

Well if there's ever any need for someone to call swift-lldb (or lldb-swift or whatever you would choose to call it) then you would probably just put it into /bin like any other executable. Since it has a different name it wouldn't conflict. You could put the relevant libraries into /lib64 if they had nonconflicting names, or into /lib64/swift if it's easier to put them into a different directory hierarchy than to rename the individual libraries.

Would ‘alternatives’ be a possibility
(https://fedoraproject.org/wiki/Packaging:Alternatives); the Swift
version of lldb is a superset of the existing lldb tool, per
https://github.com/apple/swift-lldb - “Contribution Subtleties”.

On 25 Jan 2018, at 13:46, Jason ティビツ wrote:

tibbs added a new comment to an issue you are following:
Well if there's ever any need for someone to call swift-lldb (or lldb-swift or whatever you would choose to call it) then you would probably just put it into /bin like any other executable. Since it has a different name it wouldn't conflict. You could put the relevant libraries into /lib64 if they had nonconflicting names, or into /lib64/swift if it's easier to put them into a different directory hierarchy than to rename the individual libraries.

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/issue/746

But alternatives doesn't save you from having to do all of the renaming and such to make things nonconflicting.

Alternatives just lets the administrator choose one of many executables to be the "default". So /usr/bin/lldb would turn into a symlink that after a fashion ends up pointing to lldb.swift or lldb.whatever. And of course you would have to coordinate with the lldb maintainers because they would have to rename their binary as well and start using alternatives.

Yeah, I sat down to modify the spec file to try this and realized the
same thing. Whoops.

I'm currently looking for an example of the same issue and see how they
resolved it (assuming it was resolved to everyone's satisfaction).

On 29 Jan 2018, at 13:36, Jason ティビツ wrote:

tibbs added a new comment to an issue you are following:
``
But alternatives doesn't save you from having to do all of the
renaming and such to make things nonconflicting.

Alternatives just lets the administrator choose one of many
executables to be the "default". So /usr/bin/lldb would turn into a
symlink that after a fashion ends up pointing to lldb.swift or
lldb.whatever. And of course you would have to coordinate with the
lldb maintainers because they would have to rename their binary as
well and start using alternatives.
``

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/issue/746

What if the lldb portion was split into its own package (e.g. "swift-lang-lldb") and it has a dependency on swift-lang, but swift-lang does not have a dependency on it. The LLDB portion is necessary for the REPL but not for compiling or running Swift code so the user would not explicitly need it to make Swift work.

As lldb is a application used as a helper binary, this really belongs in /usr/libexec/swift or similar.

As the maintainer of the Swift packaging in Fedora, you should also try to establish a good rapport with upstream and try to work them toward making it so upstream LLDB works for Swift.

I have been in conversation with the Swift folks in the Swift-LLDB forum,
and I think a good conversation is taking place:

https://forums.swift.org/t/lldb-renaming-for-linux-packaging/8898/18 (worth
it to read the whole thread).

The issue, as far as I can tell, is simply the effort to make it happen; I
am trying to do the work for them by figuring out how to have a renamed
lldb work with swift, but so far I haven't had any success, and a lot has
to be compiled before it errors out, so it takes quite awhile. Upgrading to
a 16-core machine helps but it's definitely all happening in very slow
motion.

On Wed, Jan 31, 2018 at 8:28 PM, Neal Gompa pagure@pagure.io wrote:

ngompa added a new comment to an issue you are following:
` Aslldbis a application used as a helper binary, this really belongs in/usr/libexec/swift` or similar.

As the maintainer of the Swift packaging in Fedora, you should also try to
establish a good rapport with upstream and try to work them toward making
it so upstream LLDB works for Swift.
``

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/issue/746

Say, looking through the spec,
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html), what if
I put all the accompanying files (lldb, et al) in /usr/libexec/swift and
have just the swift executable in /usr/bin? This, theoretically, should
be okay.

On 29 Jan 2018, at 13:36, Jason ティビツ wrote:

tibbs added a new comment to an issue you are following:
``
But alternatives doesn't save you from having to do all of the
renaming and such to make things nonconflicting.

Alternatives just lets the administrator choose one of many
executables to be the "default". So /usr/bin/lldb would turn into a
symlink that after a fashion ends up pointing to lldb.swift or
lldb.whatever. And of course you would have to coordinate with the
lldb maintainers because they would have to rename their binary as
well and start using alternatives.
``

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/issue/746

Say, looking through the spec,
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html), what if
I put all the accompanying files (lldb, et al) in /usr/libexec/swift and
have just the swift executable in /usr/bin? This, theoretically, should
be okay.

This is permitted. In fact, this is what I suggested earlier...

Oh, right, yes, sorry about that, I guess I missed it earlier. Thanks
for the great idea!

On 6 Feb 2018, at 14:33, Neal Gompa wrote:

ngompa added a new comment to an issue you are following:
``

Say, looking through the spec,
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html), what
if
I put all the accompanying files (lldb, et al) in /usr/libexec/swift
and
have just the swift executable in /usr/bin? This, theoretically,
should
be okay.

This is permitted. In fact, this is what I suggested earlier...
``

To reply, visit the link below or just reply to this email
https://pagure.io/packaging-committee/issue/746

I believe I've resolved the outstanding issues. Updated spec and RPMs are at https://tachoknight.fedorapeople.org/swift-lang/. I tested installing my swift-lang package alongside lldb installed via dnf on a F27 instance and everything works fine.

Swift 4.1 is not yet officially released yet (I'm guessing in a couple of months); is it too early to go through the review process for the spec and RPM, or should I wait until 4.1 is officially available and then mark it as reviewable?

Ron

I don't think there's anything else for us to do here.