--- /dev/null
+GEM
+ remote: https://rubygems.org/
+ specs:
+ addressable (2.7.0)
+ public_suffix (>= 2.0.2, < 5.0)
+ colorator (1.1.0)
+ concurrent-ruby (1.1.7)
+ em-websocket (0.5.2)
+ eventmachine (>= 0.12.9)
+ http_parser.rb (~> 0.6.0)
+ eventmachine (1.2.7)
+ ffi (1.13.1)
+ forwardable-extended (2.6.0)
+ http_parser.rb (0.6.0)
+ i18n (1.8.5)
+ concurrent-ruby (~> 1.0)
+ jekyll (4.1.1)
+ addressable (~> 2.4)
+ colorator (~> 1.0)
+ em-websocket (~> 0.5)
+ i18n (~> 1.0)
+ jekyll-sass-converter (~> 2.0)
+ jekyll-watch (~> 2.0)
+ kramdown (~> 2.1)
+ kramdown-parser-gfm (~> 1.0)
+ liquid (~> 4.0)
+ mercenary (~> 0.4.0)
+ pathutil (~> 0.9)
+ rouge (~> 3.0)
+ safe_yaml (~> 1.0)
+ terminal-table (~> 1.8)
+ jekyll-archives (2.2.1)
+ jekyll (>= 3.6, < 5.0)
+ jekyll-paginate (1.1.0)
+ jekyll-sass-converter (2.1.0)
+ sassc (> 2.0.1, < 3.0)
+ jekyll-seo-tag (2.7.1)
+ jekyll (>= 3.8, < 5.0)
+ jekyll-srcset-tag (0.2.0)
+ jekyll (>= 2.0.0)
+ mini_magick (~> 4.3)
+ nokogiri (~> 1.6)
+ jekyll-watch (2.2.1)
+ listen (~> 3.0)
+ kramdown (2.3.0)
+ rexml
+ kramdown-parser-gfm (1.1.0)
+ kramdown (~> 2.0)
+ liquid (4.0.3)
+ listen (3.2.1)
+ rb-fsevent (~> 0.10, >= 0.10.3)
+ rb-inotify (~> 0.9, >= 0.9.10)
+ mercenary (0.4.0)
+ mini_magick (4.10.1)
+ mini_portile2 (2.4.0)
+ nokogiri (1.10.10)
+ mini_portile2 (~> 2.4.0)
+ pathutil (0.16.2)
+ forwardable-extended (~> 2.6)
+ peach (0.5.1)
+ public_suffix (4.0.6)
+ rb-fsevent (0.10.4)
+ rb-inotify (0.10.1)
+ ffi (~> 1.0)
+ rexml (3.2.4)
+ rouge (3.24.0)
+ safe_yaml (1.0.5)
+ sassc (2.4.0)
+ ffi (~> 1.9)
+ terminal-table (1.8.0)
+ unicode-display_width (~> 1.1, >= 1.1.1)
+ unicode-display_width (1.7.0)
+
+PLATFORMS
+ ruby
+
+DEPENDENCIES
+ jekyll
+ jekyll-archives
+ jekyll-paginate
+ jekyll-seo-tag
+ jekyll-srcset-tag
+ peach
+
+BUNDLED WITH
+ 1.17.3
create_file(directory, filename, content, title, editor)
end
+# rake prepare
+desc "Prepare the system and install all thats neccessary"
+multitask :prepare do |t, args|
+ execute("sudo apt install bundler")
+ execute("bundle install --path=_vendor")
+end
+
# rake build
desc "Build the site, optionally with changed destination path"
multitask :build, :option do |t, args|
option = args[:option]
if option.nil? or option.empty?
- execute("jekyll build")
+ execute("bundle exec jekyll build")
else
- execute("jekyll build -d #{option}")
+ execute("bundle exec jekyll build -d #{option}")
end
end
interrupted = false
trap("INT") { interrupted = true }
if option.nil? or option.empty?
- execute("jekyll serve --incremental --watch")
+ execute("bundle exec jekyll serve --incremental --watch")
else
if option == "drafts"
- execute("jekyll serve --watch --drafts")
+ execute("bundle exec jekyll serve --watch --drafts")
else
- execute("jekyll serve --watch --limit_posts #{option}")
+ execute("bundle jekyll serve --watch --limit_posts #{option}")
end
end
if interrupted
--- /dev/null
+---
+layout: post
+title: Debian NEW Queue, Rust packaging
+categories:
+- debian
+- ftpmaster
+tags:
+- NEW
+- rust
+date: '2020-11-01 12:56:22 +0100'
+---
+# Debian NEW Queue
+
+So for some reason I got myself motivated again to deal with some
+packages in Debians [NEW Queue](https://ftp-master.debian.org/new.html).
+We had 420 source packages waiting for some kind of processing when I
+started, now we are down to something [around
+10](https://ftp-master.debian.org/stat.html). (Silly, people keep
+uploading stuff...)
+
+That's not entirely my own work, others from the team have been active
+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
+their packages, especially that dreaded task of getting the copyright
+file written seems to be one that is handled much better.
+
+# Rust
+
+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.
+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
+crates, and you manage what your stuff needs and provides with a tool
+called *cargo*.
+
+A library (one per crate) can provide multiple features, say a TLS lib
+can link against gnutls or openssl or some other random
+implementation. Such features may even be combinable in various
+different ways, so one can have a high number of possible feature
+combinations for one crate.
+
+There is a tool called {% deb_pkg debcargo %} which helps creating a
+Debian package out of a crate. And that tool generates so-called
+***feature-packages***, one per feature / combination thereof.
+
+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
+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.
+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.
+ - 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.
+
+## Solutions
+
+Currently we do not have a good one. The rust maintainers and the ftp
+team are talking, exploring various ideas, we will see what will come
+out.
+
+
+# Devel archive
+
+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.
+
+What?
+
+Well, take golang as an example. While we have a load of
+golang-something packages in Debian, and they are used for building
+applications written in go - none of those golang-something are meant
+to be installed by users. If you use the language and develop in it,
+the **go get** way is the one you are expected to use.
+
+So having an archive (or maybe component like main or contrib) that,
+by default, won't be activated for users, but only for things like
+buildds or archive rebuilds, will make one problem (hated metadata
+bloat) be evaluated wildly different.
+
+It may also allow a more relaxed processing of binary-NEW (easier
+additions of new feature packages).
+
+## But but but
+
+Yes, it is not the most perfect solution. Without taking much energy
+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.
+ - 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).
+ So, no idea how many rusty knives they want to sink into our nice
+ bodies for that idea...
+
+# Final
+
+Well, it is still very much open. Had an IRC meeting with the rust
+people, will have another end of November, it will slowly go forward.
+And maybe someone comes up with an entire new idea that we all love.
+Don't know, time will tell.
projects / blog.git / commitdiff