| LeePen | golinux: the solution for end users is to install usrmerge. | 18:31 |
|---|---|---|
| LeePen | gnu_srs: I don't think you have convinced myself, bb|hcb or rrq (please correct me if I am wrong in here) that there is a sustainable way to fork packages and avoid usrmerge. | 18:33 |
| gnu_srs1 | I'm submitting a file to devuan-dev now with files I have patched (and some more to check). Patches for these package will be sent later. | 18:37 |
| gnu_srs1 | Is a tar file OK? | 18:37 |
| LeePen | I don't think it will make any difference. I believe you are underestimating the work that will be required. | 18:39 |
| LeePen | For example | 18:40 |
| LeePen | src:grep has just moved grep to /usr/bin: https://tracker.debian.org/media/packages/g/grep/changelog-3.11-4 | 18:40 |
| LeePen | That means that every reference to /bin/grep would need forking and changing. | 18:41 |
| LeePen | See the list here: https://codesearch.debian.net/search?q=%2Fbin%2Fgrep&perpkg=1 | 18:41 |
| gnu_srs1 | File sent! No, grep is already patched, no files referencing /bin/grep have to change :) | 18:47 |
| gnu_srs1 | The fix is to selectively revert some (a few) packages to _not_ move the binaries/libraries to /usr. | 18:48 |
| gnu_srs1 | And people having the usrmerge aliasing install will not be affected :) | 18:49 |
| LeePen | Debian's intention is to move everything to /usr. We do not have the resources to fork and maintain all of those packages. | 18:50 |
| gnu_srs1 | I'm currently running a Ceres image with all the patched packages installed. No problems so far! | 18:51 |
| bb|hcb | IMhO the problem is even more complex. Patching grep to revert the move will not fix all the upcoming packages that will reference /usr/bin/grep | 18:51 |
| LeePen | Exactly | 18:51 |
| gnu_srs1 | The number of packages is _small_ | 18:51 |
| LeePen | Only becaus the process is only just starting. | 18:51 |
| LeePen | Debian's intention is to move *everything*. | 18:52 |
| gnu_srs1 | Yes, I know it has just started. | 18:52 |
| gnu_srs1 | And why should moved packages hardcode /usr/bin/grep? Bad practice! | 18:53 |
| LeePen | I am not justifying it. | 18:53 |
| bb|hcb | I will give another example - a friend recently installed Devuan daedalus and the mosquito framework and daemon. The init scripts are broken and need manual fix. That is not the case with the systemd unit. And that is because the count of Devuan users who tried mosquito are very close to zero | 18:53 |
| gnu_srs1 | PATH should be used wherever possible to avoid such problems. | 18:53 |
| LeePen | It is ugly and bad, | 18:53 |
| LeePen | but we don't have that control. | 18:53 |
| bb|hcb | In other words, the fact that yours or mine system works fine is not a measure that the distro is good as a whole | 18:54 |
| golinux | Thank you for some clarification! | 18:54 |
| gnu_srs1 | Regarding mosquito framework I don't know anything :( | 18:54 |
| * golinux is trying to cook b'fast so been afk . . . | 18:55 | |
| gnu_srs1 | LeePen: Is PATH ugly compared to hard-coded paths?? | 18:55 |
| golinux | gnu_srs1: This task requires knowing EVERYTHING! | 18:56 |
| gnu_srs1 | golinux: What?? | 18:56 |
| LeePen | No, ugly referred to usrmerge. | 18:56 |
| golinux | It it very complex | 18:57 |
| bb|hcb | gnu_srs1: Me neither, it is some home automation, IOT, whatever... Just an example of a rare case that easily goes unnoticed and unfixed | 18:57 |
| LeePen | I propose this: http://dpaste.com/3QJTR8HJ8 | 18:57 |
| gnu_srs1 | OK, inform me about mosquito then. Of course I cannot do everything myself, without help no way :( | 18:57 |
| gnu_srs1 | LeePen: So you give up, sad!! | 18:59 |
| golinux | LeePen . . . if the merge is going to be unavoidable, we need to draft a clear statement including how not to hose your system in the process | 18:59 |
| LeePen | gnu_srs1: I don't see another option. | 18:59 |
| LeePen | golinux: it is trivial. Install the package. | 19:00 |
| golinux | Hoping we might find time to do that collectively . . . | 19:00 |
| gnu_srs1 | Hurd now has an emerging new distro based on Alpine Linux. Maybe I should switch to Alpine too, giving up on Devuan? | 19:00 |
| golinux | LeePen: Then we need to make that clear! | 19:01 |
| gnu_srs1 | If you do this, count me out!! | 19:01 |
| golinux | Quite a few folks have done things in the wrong order and suffered breakage. | 19:01 |
| LeePen | gnu_srs1: You don't seemt o accept that nobody else thinks your solution of forking is viable. | 19:02 |
| gnu_srs1 | LeePen: The efforts I've made so far creates a workable Devuan/Ceres. Why not let me try? You can switch to usrmerge if/when I give up. Please? | 19:25 |
| gnu_srs1 | Otherwise I might try to learn guile and switch to Guix! | 19:25 |
| gnu_srs1 | OK, lets ask the users for feedback before you announce that you are giving up? | 19:27 |
| DelTomix | gnu_srs1: its not a case of giving up. Its a case of impracticality. Every time one of those thousands of packages gets a new version update - someone on the devuan side has to update the changes back. Then again Debian updates the package, and again someone in Devuan has to re-implement the change. Maintaining is not trivial. So unless there is some innovative way to automate the process or a | 19:31 |
| DelTomix | new methodology its just not realistic | 19:31 |
| gnu_srs1 | DelTomix: Not all packages need reversing, only a few!! | 19:32 |
| DelTomix | Even if it were - what would the benefit be for Devuan to be the only distro without a merged file structure? Would it benefit the users? | 19:33 |
| gnu_srs1 | Let's ask them! | 19:33 |
| DelTomix | if you are so certain - maybe you could do it as your own fork/derivative ? | 19:34 |
| sachy | what would be the bernefit be for Devuan to be the only distro without systemd? - same argument | 19:34 |
| gnu_srs1 | Issue a poll! Fon now I've mostly found packages moving systemd files to /usr. That is of no interest to Devuan, right? | 19:35 |
| adam_free2air | sachy: no it is not. | 19:35 |
| DelTomix | no I don't think it is sachy - I get that but a directory relocation is not something that affects control over the system in the same way as systemd | 19:35 |
| amesser | Back in 90's when came in touch with Linux, /bin and usr/bin confused me. I get used to it in the meanwhile. However, I still think its not really needed. | 19:35 |
| amesser | As of my experience, people starting with Linux nowadays still stumble over this. | 19:36 |
| cosurgi | it is needed. In case if you boot into system with broken /usr partition which is usually larger than /, then /bin contains the base tools necessary to fix and mount broken /usr partition | 19:36 |
| gnu_srs1 | In the old days GNU propsoed to link /usr to /, not the other way :) | 19:37 |
| amesser | I can use usb stick to fix broken systems too. | 19:37 |
| sachy | amesser: not over SSH which is the major use case for many linux installations | 19:39 |
| adam_free2air | gnu_srs1: this is an issue better taken up upstream to debian. | 19:39 |
| amesser | where is the point in having separate /usr? /usr is somehow linked to /var/lib (e.g. apt install ins /usr while having its state in /var/lib) | 19:39 |
| gnu_srs1 | adam_free2air: Debian don't want anybody to have a different opinion, wontfix is the standard answer. | 19:40 |
| * sachy thinks usrmerge is (sadly, yet again) lost fight, lets keep resources on init freedom | 19:40 | |
| amesser | sachy: how to ssh into a system which wont mount /usr. sshd is in /usr/sbin | 19:40 |
| gnu_srs1 | adam_free2air: Ah, now I see, you are talking about upstream, not Debian. | 19:42 |
| gnu_srs1 | Upstream are not taking sides, The patches I've made reverting moves to /usr are Debian constructs!!! | 19:43 |
| sachy | amesser: oh yes, thats one of my "newinstall todo" tasks - move sshd and other networkings to root partition so its always available if it boots at l | 19:43 |
| gnu_srs1 | debian/control, rules, .install etc! | 19:44 |
| gnu_srs1 | Maybe I'll publish the patches anyway, so everybody can see how small changes are needed. (and how to detect moves to /usr, hint changelog) | 19:45 |
| gnu_srs1 | Detection possible :) :) | 19:46 |
| amesser | sachy: How do you deal with updates then? moving files back and forth on each update? | 19:46 |
| DelTomix | you should publish them - there is nothing wrong with trying idea if you are willing to show it - - what do you do when someone makes a new package that expects files to be in merged locations? You can say hardcoding is a bad practice but people will do it anyway - it will always require manual intervention and babysiting (maintainer) for EACH package that might do so. | 19:48 |
| sachy | amesser: there is a clean virtual machine which gets the update, run tests, run postcripts and deploy final tarball on the production... with every update | 19:51 |
| sachy | rather complicated process | 19:51 |
| mason | gnu_srs1: If it's any consolation, I think what's you're proposing is desireable and good, but I also think it's going to be geometrically more work as time passes. If I could have an itch scratched, it'd be forking away from libsystemd0. Ideally both! | 20:01 |
| mason | But I haven't put in the time, so I won't expect it of anyone else. If you want to fork packages to avoid usrmerge, that has value even if Devuan doesn't adopt them. | 20:02 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!