| mason | This might have already shown up here, but: https://salsa.debian.org/apt-team/apt/-/commit/99c888b5eabbb7008bf4451bc62c277f28bb925f | 01:08 |
|---|---|---|
| mason | I just learned about it. | 01:08 |
| rrq | thanks; reminded me to check my pinning | 04:44 |
| bb|hcb | mason, rrq: apt is forked, so I think that no pinning would be needed? | 13:51 |
| bb|hcb | But 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 |
| onefang | I'll say again, it's not worth the effort. Just symlink and be done. | 14:12 |
| bb|hcb | It was a rhetorical question... | 14:25 |
| helmut | hi. [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 https://subdivi.de/~helmut/dep17.html 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 least | 14:43 |
| helmut | painful to you. In particular, I think you should set up a copy of https://salsa.debian.org/helmutg/dumat | 14:43 |
| bb|hcb | helmut: Thanks! Funnily enough, usrmerge was discussed couple of lines above... | 15:01 |
| rrq | helmut: who is paying you for that and why? | 15:02 |
| onefang | My part of that discussion was "I'll say again, it's not worth the effort. Just symlink and be done." | 15:04 |
| helmut | rrq: 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 |
| helmut | On 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 |
| rrq | what's their interest in getting rid of that moratorium? | 15:34 |
| helmut | rrq: The moratorium is a cost to every developer and thus to development in general. The aim is removing that cost. | 15:35 |
| rrq | as long as files are named view their installation path there's no issue. | 15:36 |
| rrq | view=via | 15:36 |
| helmut | I 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 |
| helmut | If Devuan restructures packages (not sure whether that happens), it should run its own copy of dumat. | 15:37 |
| rrq | actually I can't see there beining a cost in keeping the moratorum, but I could imagine a cost in lifting it | 15:39 |
| rrq | again, as long as files are named view their installation path there's no issue. | 15:39 |
| helmut | There definitely is a significant cost in lifting it. | 15:39 |
| rrq | with spelling :), as long as files are named via their installation path there's no issue. | 15:39 |
| helmut | Either 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 |
| rrq | ?? | 15:40 |
| helmut | In 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 crazy | 15:40 |
| rrq | with spelling :), as long as files are named via their installation path there's no issue. | 15:41 |
| helmut | I'm fine with you not seeing issues. I can do other work then. | 15:41 |
| onefang | With symlinks there's also no issues. B-) | 15:48 |
| bb|hcb | rrq: The problem is the move itself. Debian is already doing it and lots of problems are expected to happen on the way | 15:49 |
| rrq | yeah. renaming files/programs that has documentation left-overs will be a cost.. plus of course the new learning needed | 15:50 |
| rrq | and all for no practical gain | 15:51 |
| DelTomix | onefang: seems like the research helmut has compiled points out pretty thoroughly why with symlinks there are still issues. At least with dpkg | 15:57 |
| bb|hcb | onefang: 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|hcb | I 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 |
| rrq | which problems are those? | 16:15 |
| rrq | there is apparently a commercial interest in changing the way some programs are named. | 16:18 |
| rrq | and libraries | 16:18 |
| rrq | if a program has biin named X for 20 years, there is documentation talking about that program X | 16:19 |
| rrq | if that is now changed to Y then that documentaiotn become "invalid" | 16:19 |
| rrq | so 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 X | 16:20 |
| bb|hcb | Symlinks will solve that in the long run... | 16:21 |
| bb|hcb | Please do not misunderstand, my opinion is that usrmerge is a huge effort, causing lots of issues and no gain for the general community | 16:22 |
| rrq | it's mostly a matter of who is controlling the names of files.. and gives us something to focus on besides the infestation | 16:23 |
| bb|hcb | But since Devuan is based on Debian and Debian has already took that path, the only viable option is to minimize the damage... | 16:23 |
| bb|hcb | s/took/taken/ | 16:24 |
| rrq | perhaps we're heading towards a new past where PATH is filled with application directories | 16:25 |
| bb|hcb | /c/program_files/foo/bin ? ;) :P | 16:26 |
| rrq | my view is still that as long as files are named by their installation pathname then ther is no issue | 16:26 |
| fsmithred | rrq, 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 |
| rrq | if you have relied on PATH you can still do so | 16:28 |
| DelTomix | to 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|hcb | rrq: Agreed, but they are changing in Debian. | 16:30 |
| bb|hcb | Problems will be there and a ton of pointelss work (that will contribute to the global warming) | 16:30 |
| rrq | I see the main cost bing in the inability to share documentation with non-linux settings, because the program pathnames are different | 16:37 |
| rrq | "division and confusion" | 16:39 |
| rrq | might even be across different linux platforms | 16:40 |
| helmut | rrq: 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 |
| rrq | that idea tries to enforce symlinks and ambiguity in the naming of files | 16:45 |
| helmut | DelTomix: 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 |
| helmut | So 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 |
| DelTomix | will dumat be FOSS? | 16:48 |
| helmut | DelTomix: does # SPDX-License-Identifier: GPL-3.0-or-later count? | 16:49 |
| DelTomix | just had to ask :) | 16:51 |
| helmut | DelTomix: would you run the experiment (on your development machine or something)? I'd be interested in seeing whether the report differs from the debian one | 16:55 |
| helmut | DelTomix: 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 |
| rrq | given that all except the few forked packages are directly from debian it seems rather pointless | 16:57 |
| DelTomix | I will think about that - I have to study what it reports, and right now - human bandwidth is narrow. So maybe in the future | 16:58 |
| DelTomix | yeah - I feel like the difficulties for the Debian community will be even worse | 17:01 |
| helmut | rrq: 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 |
| helmut | either 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 |
| DelTomix | thanks for reaching out to us helmut | 17:06 |
| Xenguy | +1 | 17:12 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!