libera/#devuan-dev/ Sunday, 2023-09-17

masonThis might have already shown up here, but:
masonI just learned about it.01:08
rrqthanks; reminded me to check my pinning04:44
bb|hcbmason, rrq: apt is forked, so I think that no pinning would be needed?13:51
bb|hcbBut there are things that already do not work on unmerged systems - I have stumbled upon a package maint script that started with #!/usr/bin/bash and obviously broke on unmerged system. I'd expect those to increase in numbers and the question is do we have the man power to find, fork and maintain those packages...13:54
onefangI'll say again, it's not worth the effort.  Just symlink and be done.14:12
bb|hcbIt was a rhetorical question...14:25
helmuthi. [cross post from #devuan] is there someone who'd discuss Devuan+/usr-merge with me without shooting me? context is that I'm (commercially) working on getting rid of the ctte moratorium on the Debian side and describes what we're up to. I'd like to understand how that Debian side affects Devuan and what we can reasonably do on the Debian side to make this least14:43
helmutpainful to you. In particular, I think you should set up a copy of
bb|hcbhelmut: Thanks! Funnily enough, usrmerge was discussed couple of lines above...15:01
rrqhelmut: who is paying you for that and why?15:02
onefangMy part of that discussion was "I'll say again, it's not worth the effort.  Just symlink and be done."15:04
helmutrrq: Freexian SARL is a company selling Debian LTS. It gives back by funding Debian development in selected areas. Getting rid of the file move moratorium is one such area.15:33
helmutOn the Debian side, there is quite some consensus on having base-files install the aliasing symlinks via its data.tar and having every other package move their files to /usr.15:34
rrqwhat's their interest in getting rid of that moratorium?15:34
helmutrrq: The moratorium is a cost to every developer and thus to development in general. The aim is removing that cost.15:35
rrqas long as files are named view their installation path there's no issue.15:36
helmutI expect the moratorium to be lifted soon and then files will be moved from / to /usr. This will cause problems that we intend to detect and mitigate on the Debian side using dumat.15:37
helmutIf Devuan restructures packages (not sure whether that happens), it should run its own copy of dumat.15:37
rrqactually I can't see there beining a cost in keeping the moratorum, but I could imagine a cost in lifting it15:39
rrqagain, as long as files are named view their installation path there's no issue.15:39
helmutThere definitely is a significant cost in lifting it.15:39
rrqwith spelling :), as long as files are named via their installation path there's no issue.15:39
helmutEither way, that question has been settled. The question now is what we can do on the Debian side to ease it on your side.15:40
helmutIn a not so distant future Debian will likely have no files left in /bin, /lib or /sbin. That implies e.g. /usr/bin/sh and other things you may find crazy15:40
rrqwith spelling :), as long as files are named via their installation path there's no issue.15:41
helmutI'm fine with you not seeing issues. I can do other work then.15:41
onefangWith symlinks there's also no issues.  B-)15:48
bb|hcbrrq: The problem is the move itself. Debian is already doing it and lots of problems are expected to happen on the way15:49
rrqyeah. renaming files/programs that has documentation left-overs will be a cost.. plus of course the new learning needed15:50
rrqand all for no practical gain15:51
DelTomixonefang: seems like the research helmut has compiled points out pretty thoroughly why with symlinks there are still issues. At least with dpkg15:57
bb|hcbonefang: Symlinks do not solve everything, e.g. there are races when a package installs /bin/foo and another replaces it with /usr/bin/foo...16:06
* onefang wonders why that would be a thing in the first place?16:08
bb|hcbI really appreciate helmut being involved with this change and also including Devuan, so our voice is heard and we can work together on solving the problems...16:09
rrqwhich problems are those?16:15
rrqthere is apparently a commercial interest in changing the way some programs are named.16:18
rrqand libraries16:18
rrqif a program has biin named X for 20 years, there is documentation talking about that program X16:19
rrqif that is now changed to Y then that documentaiotn become "invalid"16:19
rrqso new documentation needs to be written and poeple onwards need to learn it is now named Y unless the system is old and then it was named X16:20
bb|hcbSymlinks will solve that in the long run...16:21
bb|hcbPlease do not misunderstand, my opinion is that usrmerge is a huge effort, causing lots of issues and no gain for the general community16:22
rrqit's mostly a matter of who is controlling the names of files.. and gives us something to focus on besides the infestation16:23
bb|hcbBut since Devuan is based on Debian and Debian has already took that path, the only viable option is to minimize the damage...16:23
rrqperhaps we're heading towards a new past where PATH is filled with application directories16:25
bb|hcb /c/program_files/foo/bin ? ;) :P16:26
rrqmy view is still that as long as files are named by their installation pathname then ther is no issue16:26
fsmithredrrq, I'm not sure I understand what you mean? Do I need to go through all my scripts and change the full paths to command that have changed location?16:27
rrqif you have relied on PATH you can still do so16:28
DelTomixto enforce the path is up to Debian Packaging rules isn't it? to enforce that will probably cause dropping of many upstreams that don't conform - such as due to not being actively maintained.16:29
bb|hcbrrq: Agreed, but they are changing in Debian.16:30
bb|hcbProblems will be there and a ton of pointelss work (that will contribute to the global warming)16:30
rrqI see the main cost bing in the inability to share documentation with non-linux settings, because the program pathnames are different16:37
rrq"division and confusion"16:39
rrqmight even be across different linux platforms16:40
helmutrrq: My understanding is that documentation will not have to change. While the intention is to move files in data.tar, the aliasing symlinks ensure that the previous location is still accessible and existing documentation is still valid.16:44
rrqthat idea tries to enforce symlinks and ambiguity in the naming of files16:45
helmutDelTomix: The vast majority of problems I see is with the process of moving files from / to /usr. Once that is complete, my expectation is that we can move on without having to deal with this on a regular basis. I hope I'm right about that.16:46
helmutSo is there someone on the Devuan side who'd set up and run dumat (once or continously)? If yes, you may open an issue in the salsa project for support questions.16:48
DelTomixwill dumat be FOSS?16:48
helmutDelTomix: does # SPDX-License-Identifier: GPL-3.0-or-later count?16:49
DelTomixjust had to ask :)16:51
helmutDelTomix: would you run the experiment (on your development machine or something)? I'd be interested in seeing whether the report differs from the debian one16:55
helmutDelTomix: rough cost: you'll need a bit more than 1gb of disk space for a sqlite db. you'll be download all binary packages for one architecture (<- that's a lot of bandwidth).16:56
rrqgiven that all except the few forked packages are directly from debian it seems rather pointless16:57
DelTomixI will think about that - I have to study what it reports, and right now - human bandwidth is narrow. So maybe in the future16:58
DelTomixyeah - I feel like the difficulties for the Debian community will be even worse17:01
helmutrrq: problems may arise from the intraction of packages. so any package you change may produce an issue with any other package. this is also why I didn't just added a check for lintian: it lacks that archive-wide view.17:03
helmuteither way. you now know about me predicting possible issues and you know how to reach me. thanks for listening. I hope this works out for you.17:04
DelTomixthanks for reaching out to us helmut17:06

Generated by 2.17.0 by Marius Gedminas - find it at!