Small fixes
authorJoerg Jaspert <joerg@debian.org>
Mon, 2 Nov 2020 21:08:43 +0000 (22:08 +0100)
committerJoerg Jaspert <joerg@debian.org>
Mon, 2 Nov 2020 21:08:43 +0000 (22:08 +0100)
_posts/2020-11-01-debian-new-queue,-rust-packaging.md

index 4932347..293ad27 100644 (file)
@@ -23,9 +23,12 @@ too, but for those few days I went through a lot of stuff waiting. And
 must say it still feels mostly like it did when I somehow stopped
 doing much in NEW.
 
-Except, that I feel that maintainers are much better in preparing
+Except - well, I **feel** that maintainers are much better in preparing
 their packages, especially that dreaded task of getting the copyright
-file written seems to be one that is handled much better.
+file written seems to be one that is handled much better. Now, thats
+not supported by any real numbers, just a feeling, but a good one, I
+think.
+
 
 # Rust
 
@@ -33,11 +36,12 @@ Dealing with NEW meant I got in contact with one part that currently
 generates some friction between the FTP Team and one group of package
 maintainers - the Rust team.
 
-Note that this is, of course, entirely written from my point of view.
+Note: this is, of course, entirely written from my point of view.
 Though with the intention of presenting it as objective as possible.
 Also, I know what rust is, and have tried a "Hello world" in it, but
 that's about my *deep* knowledge of it...
 
+
 ## The problem
 
 Libraries in rust are bundled/shipped/whatever in something called
@@ -57,22 +61,23 @@ Debian package out of a crate. And that tool generates so-called
 Those feature packages are empty packages, only containing a symlink
 for their */usr/share/doc/...* directory, so their size is smaller
 than the metadata they will produce. Inside the archive and the files
-generated by it, so stuff that every user everywhere has to download
+generated by it, stuff that every user everywhere has to download
 and their apt has to process. Additionally, any change of those feature
 sets means one round through NEW, which is also not ideal.
 
 
-So naturally, the FTP Team dislikes those empty feature packages.
+So, naturally, the FTP Team dislikes those empty feature packages.
 Really, a lot.
 
 There appears to be a different way. Not having the feature packages,
 but putting all the combinations into a *Provides* header. That
 sometimes works, but has two problems:
 
- - It can generate really long Provides: lines. I mean, REALLY REALLY
-   long. Somewhat around 250kb is the current record. Thats long
-   enough that a tool (not dak itself) broke on it. Sure, that tool
-   needs to be fixed, but still, that's not nice. Currently preferred, though.
+ - It can generate really long Provides: lines. I mean, REALLY
+   **REALLY** ***REALLY*** long. Somewhat around 250kb is the current
+   record. Thats long enough that a tool (not dak itself) broke on it.
+   Sure, that tool needs to be fixed, but still, that's not nice.
+   Currently preferred from us, though.
  - Some of the features may need different dependencies (say, gnutls
    vs openssl), should those conflict with each other, you can not
    combine them into one package.
@@ -84,15 +89,15 @@ team are talking, exploring various ideas, we will see what will come
 out.
 
 
-# Devel archive
+# Devel archive / Component
 
 One of the possible solutions for the feature package problem would be
 something that another set of packages could also make good use of, I
-think. The introduction of a new archive, meant only for packages that
-are needed to build something, but where users are discouraged from
-ever using them.
+think. The introduction of a new archive or component, meant only for
+packages that are needed to build something, but where users are
+discouraged from ever using them.
 
-What?
+_What_?
 
 Well, take golang as an example. While we have a load of
 golang-something packages in Debian, and they are used for building
@@ -115,7 +120,8 @@ to think about, it requires
  - an adjustment in how main is handled. Right now we have the golden
    rule that *main is self contained*, that is, things in it may not
    need anything outside it for building or running. That would need
-   to be adjusted for building.
+   to be adjusted for building. (Go as well as *currently* rust are
+   always building static binaries, so no library dependencies there).
  - It would need handling for the release, that is, the release team
    would need to deal with that archive/component too. We haven't,
    yet, talked to them (still, slowly, discussing inside FTP Team).