[This is more a brainstorm than a "finished" bug report.
I hope it's still useful!]

When not using mmdebstrap, I have something like this[0].
I could just specify an exact debian.sources to mmdebstrap on stdin, but
I'd rather have mmdebstrap take care of it for me (less code for me).
I can get close with

    mmdebstrap --components=main,contrib,non-free buster

I think the only differences are missing backports and proposed-updates.
I don't REALLY need proposed-updates, but I rely heavily on backports,
for things like smartmontools and linux-image-amd64.
It's also useful for debhelper &c.

I thought about asking for something like --enable-backports.
Then it occurred to me that backports Release already has

    NotAutomatic: yes
    ButAutomaticUpgrades: yes

So, is it reasonable for mmdebstrap to ALWAYS enable backports for suites that have it?
You're already always including volatile ($suite-updates).
I think it would look like this[2] (because unstable/testing don't have backports).

One potential gotcha is, I think, it takes a few weeks for foo-backports to appear when foo changes from testing to stable.
We don't want to break "mmdebstrap stable" during that period!

It will also make mmdebstrap slightly slower[3] for everyone.




[0] in ansible's yaml/jinja2 markup (sorry it's a bit messy),

    - name: Minimum sources.list (Debian 10+).
      when: is_buster_or_newer
      copy:
        dest: /etc/apt/sources.list.d/debian.sources
        content: |
          # Ref. https://manpages.debian.org/stable/apt/sources.list.5.en.html#DEB822-STYLE_FORMAT
          # NOTE: apt 1.5+ supports https natively (no apt-transport-https needed)
          # UPDATE: Using https *and* caching proxy proved to be too problematic.
          #         Therefore we now use SOLELY http (not https).
          # NOTE: intel-microcode & amd64-microcode needs contrib & non-free!
          # FIXME: is it safe to place deb.debian.org and security.debian.org together?
          # UPDATE: SOLELY deb.debian.org (no security.debian.org),
          #         which is identical to security-cdn.debian.org,
          #         which is identical to security.debian.org (mostly) due to SRV records.
          {% if codename == 'sid' %}
          # Debian unstable (sid) has no security repo.
          {% else %}
          Types: deb
          URIs: http://deb.debian.org/debian-security
          Suites:
          {% if codename == 'buster' %}
          # NOTE: Debian 11+ use "foo-security" (not "foo/updates").
            {{codename}}/updates
          {% else %}
            {{codename}}-security
          {% endif %}
          Components: main contrib non-free
          {% endif %}

          Types: deb
          URIs: http://deb.debian.org/debian
          Suites:
          {% if kind == 'unstable' %}
            unstable
            experimental
          {% elif kind == 'testing' %}
            {{codename}}
            unstable
            experimental
          {% else %}
            {{codename}}
            {{codename}}-updates
            {{codename}}-proposed-updates
            {{codename}}-backports
          {% endif %}
          Components: main contrib non-free

[2]

    diff -ud --label /usr/bin/mmdebstrap --label \#\<buffer\ mmdebstrap\> /usr/bin/mmdebstrap /tmp/buffer-content-yBjfzf
    --- /usr/bin/mmdebstrap
    +++ #<buffer mmdebstrap>
    @@ -3304,6 +3304,14 @@
                         $sourceslist
                           .= "deb$signedby $mirror $suite-updates $compstr\n";
    +                    if (
    +                        not any { $_ eq $suite } (
    +                            'unstable', 'testing', 'sid', 'bullseye'
    +                        )
    +                    ) {
    +                        $sourceslist
    +                          .= "deb$signedby $mirror $suite-backports $compstr\n";
    +                    }
                         if (
                             any { $_ eq $suite } (
                                 'oldoldstable', 'oldstable',
                                 'stable',       'jessie',


[3] Oops, can't feed a .sources format, so I'll just extract what mmdebstrap wrote itself...

        # mmdebstrap buster --variant=extract --include=netbase - >/dev/null - < /etc/apt/sources.list.d/debian.sources
        E: Type 'Types:' is not known on line 10 in source list /tmp/mmdebstrap.v2GZdxqlM9/etc/apt/sources.list

        # mmdebstrap buster --variant=extract --include=netbase | tar xv --strip-components=3 ./etc/apt/sources.list
        I: creating tarball...
        ./etc/apt/sources.list

        # cat sources.list
        deb http://deb.debian.org/debian buster main
        deb http://deb.debian.org/debian buster-updates main
        deb http://security.debian.org/debian-security buster/updates main

    Looks like it makes "apt update" about 10% slower (0.5s) with cold cache.

        # command time mmdebstrap buster --variant=extract --include=netbase - >/dev/null sources.list --quiet
        3.19user 0.58system 0:04.47elapsed 84%CPU (0avgtext+0avgdata 49088maxresident)k
        6444inputs+0outputs (0major+58036minor)pagefaults 0swaps

        # echo deb http://deb.debian.org/debian buster-backports main >>sources.list
        # command time mmdebstrap buster --variant=extract --include=netbase - >/dev/null sources.list --quiet
        3.29user 0.64system 0:05.01elapsed 78%CPU (0avgtext+0avgdata 49924maxresident)k
        7259inputs+0outputs (0major+66213minor)pagefaults 0swaps

Quoting Trent W. Buck (2020-02-11 10:11:18)
Backports is not really fully part of the official Debian - e.g. has a
radically different support policy and does not use Debian bugtracker.


 - Jonas

Hi,

six years later, we hope that I'm smarter today when it comes to reasoning
about software architecture and interface design than I was back then.

TLDR: I think this is a bad idea.

Quoting Trent W. Buck (2020-02-11 10:11:18)

Yes. Others with the same idea can now read the arguments you and I made in
this bug.

The problem with "less code for me" is, that it is less code for you and
probably only for you. When developing mmdebstrap I have to have all kinds of
use-cases in mind and adding options which are too specific is a bad idea. I
wrote a longer message about that topic here:
https://gitlab.mister-muffin.de/josch/mmdebstrap/issues/26#issuecomment-751

I don't doubt that it's useful. I also often use backports.

Yes, because that's a frequent wishlist feature for debootstrap but debootstrap
cannot do it because it's limited to a single mirror.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762222
be necessary to think about which default to pick.

Here is my take on the topic: I'm against adding backports by default and I'm
against a --enable-backports option.

mmdebstrap includes security mirrors by default when creating a chroot of a
stable distro. I think this makes sense because it's a frequently requested
feature for debootstrap and because I believe that security fixes should be the
default and not a nice extra. To disable this automatism, you just supply
https://deb.debian.org/debian as the mirror.

I think backports are different. Backports are not enabled by default when
installing a new Debian installation for a reason. If they were, we could
re-open this discussion because then expectations are different. If you want
backports, the user should educate themselves about the drawbacks of enabling
them and then take the necessary steps to enable them.

Why no --enable-backports option. For once, it would be very distro specific.
Not every distro has this concept. Furthermore, we already have hooks to enable
backports so any such option would only be useful if we argue that mmdebstrap
is run from the command line by hand. But this is not the case in your
situation. You are scripting it and thus there is no downside for you when you
run your scripts. Your scripts are doing the work. You don't type more.

Any option you add has to be maintained forever because people will start
relying on it and then you can never remove it. We have to be very careful with
which option we add because of feature creep (see the link to the mmdebstrap
upstream issue #26 above).

Good, so you can script around this. We would have a different conversation if
you wanted mmdebstrap to do this when running mmdebstrap by hand from the
command line. When you run mmdebstrap as part of a script, then it is much less
of a problem if you have to encode your specific requirements in that script.

If we were talking about an option like --enable-backports for those who run
this from the command line by hand, we would have to consider different
trade-offs.

Not everybody has internet as fast as yours. For me, just downloading the
Packages file for bookworm-backports takes 1.5 seconds. If 10% is 0.5 seconds,
then it seems you can run mmdebstrap in 5 seconds which brings me to the next
points:

Not everybody has a computer as fast as yours. For me, running the mmdebstrap
invocation above but for bookworm takes 17 seconds. Adding backports adds
another 3 seconds to that.

Thanks!

cheers, josch

For the record,

Your points are all reasonable, and I am OK with this outcome.
Thanks for taking the time to reason it out clearly.

Quoting Trent W. Buck (2026-10-08 06:12:54)

Thank you! Then also "for the record" :) I am glad you are posting bug reports
like this because they confront me with a different perspective and having to
spell out *why* things are as they are forces one to re-evaluate whether they
are a good idea or not. And sometimes this means that things are getting
changed. Not all the time (not this time for example) but at the very least,
this bug and my arguments are publicly recorded and now others can read them
and challenge me on my points in the future.

Thanks!

cheers, josch