Add Debian packaging policy and sample package documents.

[futurejones]

Added a Debian Policy document to outline the procedure to get packages accepted into the official Debian repositories. I have included links to reference docs for further information.

Included in the PR are sample build instructions for a ubuntu/focal deb package for initial testing. The test results have been reported in SR-15515.

While testing I created several packages to test the alternate installation locations as discussed in previous PR's opt and libexec.
It appears that like fedora, debian does not allow installation in the opt directory.
Installation into the libexec also caused many warnings.

[shahmishal]

Thanks @futurejones for the policy, it looks good to me.

[shahmishal]

cc: @tomerd for additional review

[shahmishal]

Installation into the libexec also caused many warnings.

What kind of warnings are we seeing here?

[futurejones]

opt gives the following error for every file found in opt

E: swiftlang: dir-or-file-in-opt opt/bin/
N: 
N:    Debian packages should not install into /opt, because it is reserved for
N:    add-on software.
N:    
N:    Refer to Filesystem Hierarchy Standard (/opt : Add-on application
N:    software packages) for details.
N:    
N:    Severity: error
N:    
N:    Check: files/hierarchy-standard

libexec gives the following warning for every file found in libexec

W: swiftlang: file-in-unusual-dir libexec/swift/bin/clang
N: 
N:    This file or symbolic link is in a directory where files are not
N:    normally installed by Debian packages.
N:    
N:    Severity: warning
N:    
N:    Check: files/hierarchy-standard

[shahmishal]

@drexin pointed out we might be able to use /usr/lib instead of /usr/libexec on Debian. @futurejones thoughts?

https://lists.debian.org/debian-devel/2005/05/msg00401.html

[futurejones]

@shahmishal, I was looking at the same thing. /usr/lib is used by a large number of existing installations in Debian and Ubuntu.
The official Debian usage of the /usr/lib directory does allow for more complex programs with subdirectories.
https://manpages.debian.org/bullseye/manpages/hier.7.en.html
Where as the usage /usr/libexec is more restricted.
I will build some new packages using /usr/lib and run some tests.

[shahmishal]

@futurejones Did /usr/lib option work?

[futurejones]

@shahmishal
Yes /usr/lib seems to be a viable option. I have been doing a heap of testing and so far there have been no errors or warnings about using usr/lib.

I was looking at the symlinks needed for swift, swiftc in /usr/bin

ln -fs %{_libexecdir}/swift/bin/swift %{buildroot}%{_bindir}/swift
ln -fs %{_libexecdir}/swift/bin/swiftc %{buildroot}%{_bindir}/swiftc

Currently they are being linked to swift and swiftc but these are already symlinks to swift-frontend.
Should we be linking directly to swift-frontend?

[shahmishal]

Should we be linking directly to swift-frontend?

I dont think so, do you see any benefits on linking directly?

[futurejones]

I don't know of any benefit, I was just wondering as to the reasoning of creating symlinks to symlinks.

[shahmishal]

@futurejones This is ready to be merged once we update the doc to contain the info about using /usr/lib and which binaries will be symlink.

[futurejones]

@shahmishal @tomerd @jblache
#90 indicates that you are no longer taking items discussed and approved in this PR with any importance. Also it is very clear that the whole Debian packaging system is no longer being discussed openly in the community and is being handled in house and only by paid apple employees.
It appears that community input is no longer wanted or needed.
I am closing this PR as it is not relevant anymore.

[tomerd]

@futurejones sorry to hear that the work on #90 had left this impression, it was not the intention and my guess is that what we have here is a communication breakdown of some sorts

the work on #90 started since this PR and more generally debian packaging had no progress for many months. there is a strong desire to make progress on offering debian packages along side the RPMs swift.org is already offering. very much like this PR, #90 is a proposal - a PR that is open for community review, feedback and discussion. this project welcomes the involvement of everyone that cares to contribute to the effort including Apple employees and community members