Control: tag -1 + wontfix 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) > [This is more a brainstorm than a "finished" bug report. > I hope it's still useful!] Yes. Others with the same idea can now read the arguments you and I made in this bug. > I'd rather have mmdebstrap take care of it for me (less code for me). 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 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 don't doubt that it's useful. I also often use backports. > 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). 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 > 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. Yes, any such option would also need a --disable-backports variant and it would 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). > [0] in ansible's yaml/jinja2 markup (sorry it's a bit messy), 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. > [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. 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
signature.asc
Description: signature
