Colin Watson wrote: > Oh, bah, I meant DISTRIB_CODENAME. Sorry, fixing. Ok at least the change won't affect d-i now as we don't currently include a DISTRIB_CODENAME (since the d-i "distribution" does not have a codename..) > > I don't follow the reasoning that connects DISTRIB_RELEASE with > > PREFERRED_DISTRIBUTION either. DISTRIB_RELEASE has a specific format and > > contents required by lsb stuff, while PREFERRED_DISTRIBUTION is whatever > > debian distribution name we need to set it to today to make d-i work > > well. > > Debian-derived distributions that do code modifications are (I think) > always going to set DISTRIB_CODENAME to a valid suite name if they > modify lsb-release. It's an obvious single place to look to get the > current suite name. In Ubuntu I added an lsb-release-udeb so that we > could get at it from d-i easily, but setting it at initrd build time > works just as well; the general idea was to save derivatives from having > to rebuild choose-mirror just to fiddle with PREFERRED_DISTRIBUTION. It still feels weird to me to co-opt the lsb release file to do something other than provide info about the d-i distribution to lsb-aware programs. I'd feel sort of the same if apt began defaulting to reading /etc/lsb-release and installing the distribution there. > > Now, we could add an internal-use debconf question instead of the > > hardcoded PREFERRED_DISTRIBUTION string or something like that.. > > That's slightly better than the hardcoded string certainly, but I think > using DISTRIB_CODENAME makes sense and is less work for people building > derivatives (because it's the same amount of initrd modification to > fiddle /etc/lsb-release versus adding a preseed, and the former can deal > with all default-suite-related things at once). Well I don't know of anything else suite-related in d-i that might look at this file, which is specific to d-i after all. -- see shy jo
Attachment:
signature.asc
Description: Digital signature