> > That would mean a new feature, localization, plus long term maintenance
I appreciate that there is development effort associated with features but my interpretation of what you are saying is that concerns about a LUKS name can be ignored at least in terms of the Debian installer. Is my interpretation incorrect? Does this mean that concerns regarding long term maintenance would result in a patch to implement my desired behavior being rejected? Or that to be accepted such a patch would have to not only include the desired change but also all localization requirements to be implemented as well? That benefits only users who care about that kind of things, so that > really doesn't seem to be a question that should get asked in the first > place. Are you suggesting that caring about the LUKS name is an irrelevant detail and such concerns are unreasonable? Please clarify if my takeaway is incorrect here. I can somewhat understand such a position when we are talking about the difference between crypt_sda3 and crypt00 but the pending change to use a LUKS name based on UUID now brings in the context of .a change that will increase the length of a LUKS name from around a dozen characters to one that has more than 40 characters as well as the particular string that needs to be typed out going from one that can be recreated by glancing at it to one that would become effectively untypable. Please consider the burden of getting a UUID into a configuration file if someone is not using a mouse or otherwise does not have cut/paste available. It's certainly not impossible but it moves into the realm of becoming a serious hassle and outright chore. An exceedingly difficult string to type that is itself a component of operations that may need to be performed on a system that is in a degraded state is going to cause problems for people and at a point in time when they already have enough problems. I already rename the LUKS devices so for me there will be a slight increase in annoyance related to moving from crypt_sda3 to crypt_b94cc3fe-b64a-4496-bea7-745736218e6b as a part of my post install workflow. But such a change, if not possible to be overridden during install, is going to result in a significant population that previously didn't care about the LUKS name to ones that will. On Tue, Apr 22, 2025 at 3:23 PM Cyril Brulebois <k...@debian.org> wrote: > Tyler Riddle <cardboardaardv...@gmail.com> (2025-04-22): > > Not being a fan of having the backing block device be a part of the name > > used for the LUKS config using the UUID seems like a very reasonable > > change. However, as a sysadmin that has to juggle these things, I would > > rather not have to type out a UUID when I'm working on a system. Sure cut > > and paste is a thing that can be done which helps cut down on the typing > > but I am also able to formulate names myself that are shorter, easier to > > type, and will work for my use cases. > > > > I suggest the following: > > 1) Change the default name to incorporate the UUID. > > 2) Update the workflow to prompt the user for their desired name > > That benefits only users who care about that kind of things, so that > really doesn't seem to be a question that should get asked in the first > place. > > > I think this covers all concerns and imposes a very minimal level of > > overhead for users who simply want to accept whatever defaults the > > installer may select. > > That would mean a new feature, localization, plus long term maintenance, > in addition to “very minimal level of overhead” for everyone. > > > Cheers, > -- > Cyril Brulebois (k...@debian.org) <https://debamax.com/> > D-I release manager -- Release team member -- Freelance Consultant >
