debian: add initial control files for debian packaging

[compnerd]

The packaging on debian mostly requires the control files and a
pre-configured layout to package as a root. This adds the control files
as a starting point.

[compnerd]

CC: @shahmishal

[stevapple]

May consider adding a "Homepage" field here which links to https://swift.org?

[stevapple]

We'd also consider replacing swift- prefix with swiftlang-, discussion here:

https://forums.swift.org/t/rpm-and-debs-for-swift-call-for-the-community/49117/35

[tomerd]

this seems fine to me, also see #33 and specifically metadata/rpm/5.5.0/metadata.inc file which is how I envision this working for RPMs. can we align the locations / concept and metadata itself?

other question is why do we need 3 control files, did you envision 3 packages?

[compnerd]

Yes, I expect at least 3 packages initially, with more in the future (architecture variants).

[futurejones]

@tomerd, there are a number of fundamental flaws in this PR all of which highlight the need for a package design document as we discussed in #27.
The package metadata should be unified across all platforms as much as possible. There will be small differences but the key things like package name, description, license etc should be the same.

package naming ?

The package naming was commented on in a code review by @stevapple but for some reason this has been ignored.
swift-lang cannot be used as there is an entire family of swift packages already available for debian/ubuntu.
Also, linux should not be included in any package name.
A better naming would be - swiftlang, swiftlang-runtime, swiftlang-dev.

package descriptions

The package descriptions for the different versions are a bit strange -
C/C++/Objective-C/Swift Toolchain ??
Swift Development Content for Linux ??.

3 levels of swift install ?

The inclusion of multiple control files for different levels of swift install I feel is unnecessary at this point in time. There has been no discussion about different levels of install packages i.e. swift-runtime, swift-?, swift-dev.
Essentially the swift toolchain install is already swiftlang-dev as it includes a multitude of additional packages such as clang, llvm, lldb, lld, sourcekit-lsp. We even have a very old version (2016) of python-six included.

master control file template

There will be a need for many control files for all the different distributions supported but these will essentially be identical and can generated from a master control file template.
The only differences will be in the architecture, dependancies, and replaces fields.

missing metadata

This PR does not represent a working control file and is also not usable as a template as there are a number of missing and essential fields.

WIP

I know that this is all work in progress but if we don't start in the right place then this whole process will be a time consuming mess and we will never achieve the desired outcome.

[tomerd]

hi @futurejones inline

@tomerd, there are a number of fundamental flaws in this PR all of which highlight the need for a package design document as we discussed in #27.

I agree and @shahmishal is putting one together. this repo is in a work-in-progress state and no packages are to be created from it until we finalize the design questions you highlight.

The package metadata should be unified across all platforms as much as possible. There will be small differences but the key things like package name, description, license etc should be the same.

totally agree, and I also put out #33 which attempts to start the unification process from a technical side of things, with the actual content pending the design mentioned above

package naming ?

The package naming was commented on in a code review by @stevapple but for some reason this has been ignored.
swift-lang cannot be used as there is an entire family of swift packages already available for debian/ubuntu.
Also, linux should not be included in any package name.
A better naming would be - swiftlang, swiftlang-runtime, swiftlang-dev.

agree - lets discuss this more when @shahmishal puts the design doc PR out

package descriptions

The package descriptions for the different versions are a bit strange -
C/C++/Objective-C/Swift Toolchain ??
Swift Development Content for Linux ??.

agree - lets discuss this more when @shahmishal puts the design doc PR out

3 levels of swift install ?

The inclusion of multiple control files for different levels of swift install I feel is unnecessary at this point in time. There has been no discussion about different levels of install packages i.e. swift-runtime, swift-?, swift-dev.
Essentially the swift toolchain install is already swiftlang-dev as it includes a multitude of additional packages such as clang, llvm, lldb, lld, sourcekit-lsp. We even have a very old version (2016) of python-six included.

agree - lets discuss this more when @shahmishal puts the design doc PR out. fwiw I imagined two kind (one for development - full toolchain, and one for runtime - just runtime support libraries) and looks like @compnerd has 3 in mind, we should hash this out more in the design phase

master control file template

There will be a need for many control files for all the different distributions supported but these will essentially be identical and can generated from a master control file template.
The only differences will be in the architecture, dependancies, and replaces fields.

not familiar enough with debian control files, but we should discuss more

missing metadata

This PR does not represent a working control file and is also not usable as a template as there are a number of missing and essential fields.

agree - lets discuss this more when @shahmishal puts the design doc PR out

WIP

I know that this is all work in progress but if we don't start in the right place then this whole process will be a time consuming mess and we will never achieve the desired outcome.

agree again, I think the next step here is for @shahmishal to puts the design doc PR out.

[shahmishal]

What is the status of this PR? We merged the Debs package control files already.

[compnerd]

I don't think that this is needed anymore then. I think that it got held up and people just redid the work 🤷‍♂️