I’m working on a SPEC file for Apple’s swift programming language.  I believe it’s currently working and conforms to the community guidelines but I have some questions:

1) The swift name conflicts with several existing packages.  I’m thinking swiftlang would be appropriate as this is similar to the golang package.

2) Building swift is a relatively involved (and slow) process.  There are 9 different repos with code that is all inter-related.  I’m interested in how you would all suggest structuring the RPM.  I’m thinking that there should be 4 sub-packages created:

swiftlang - installs swiftlang-bin and swiftlang-lib
swiftlang-lib - Core libraries required for running a swift program
swiftlang-bin - The swift compiler and REPL (depends on swiftlang-lib)
swiftlang-docs - Associated documentation

My thinking is that tools that are built using the swift language can depend upon the swiftlang-lib package and ignore everything else.  Where as developers will want the swiftlang-bin package which includes the compiler and REPL.

Is this a good strategy?

3) Swift relies on LLDB for it’s REPL functionality on linux.  This is annoying because it creates a custom version of LLDB that conflicts with the main lldb package.  I can’t see anyway around this conflict as it is a core assumption in the swift programming language.  You can’t move the package to another location because swift searches for the first available lldb on the path.  As far as I can tell the only way to deal with this is to add a conflict with the lldb package to the swiftlang-bin package.  Any other ideas short of getting the swift crew to change a fundamental design decision?

Thanks for your help!