| Nietz | missed u all. working on something... what do you think about a pictogram/support guide for users to follow? e.g. debian wiki links for research would be lower on tree than asking question in irc. thinking it could save time having a place to point users first | 01:59 |
|---|---|---|
| golinux | Nietz: What is a "pictogram/support guide"? | 02:11 |
| golinux | This: https://www.devuan.org/os/documentation/install-guides/daedalus/install-devuan | 02:12 |
| Nietz | I'll draft something up. you'll see what i mean. | 02:20 |
| golinux | Thanks . . . | 02:23 |
| Nietz | golinux: someone did most of the work for me. pm a link to you? | 02:46 |
| golinux | Sure | 02:47 |
| gnu_srs | FYI: Void Linux is using XBPS as package manager and runit as init system. Can they be Devuan's new upstream?? | 21:23 |
| mason | And they go way past UsrMerge, and link bin and sbin! :P That said, their package infrastructure is very lacking as compared with Debian/Devuan. They have some good tooling but not enough manpower to use it fully. For instance, there's tooling for package history, but it's generally unpopulated. | 21:29 |
| gnu_srs | mason: How do they link bin and sbin? | 21:55 |
| mason | gnu_srs: They symlink. It's UsrMerge taken a step further. | 21:56 |
| mason | That said, it doesn't break for them. | 21:56 |
| rrq | it works if I remove all those links? or "works" relies on those being links (like for Debian)? | 22:08 |
| mason | rrq: Their fundamental package tools seem not to conflict with the links existing. I didn't explore it in hugely great depth, unfortunately. | 22:10 |
| mason | They've had it in place for some time now. | 22:10 |
| rrq | fair enough; so for them all /{,usr/}{,s}bin/X pathnames resolves to the same file... similarly for /{,usr/}lib{,64}/X (on a 64-bit arch) | 22:17 |
| rrq | I would guess they like debian has "*must* resolve to the same" so they can use any pathname willy-nilly | 22:21 |
| mason | I remember that why I gave up on Void was that there was no notion of packaging kernel modules outside the kernel package and having dependency relationships to control that, and active opposition to it from the developers. It came up in the context of my wanting to package ZFS kmods. | 22:26 |
| rrq | anyhow, I believe devuan is still focussed on keeping systemd out of the package collection, and not really the more general fight against the commercialisation/stupidifcation drive(s) | 22:53 |
| mason | Yeah. UsrMerge is obnoxious and broken but once the bugs have been addressed, it's merely arbitrary. | 22:54 |
| gnu_srs | mason: I still don't understand: /bin/X->/usr/bin/X etc or /bin->/sbin etc?? | 23:07 |
| rrq | it's /bin -> usr/bin, /sbin -> usr/bin and /usr/sbin -> bin | 23:08 |
| rrq | all binaries pile up in /usr/bin/ but must be referrable with or without /usr and with or without s | 23:10 |
| mason | From one of the developers: 18:42 < paper_> and /bin, /sbin, /usr/sbin are just links to /usr/bin | 23:12 |
| rrq | they are *relative* links actually (so not movable) | 23:13 |
| gnu_srs | In the old days Upstream Hurd proposed /->/usr which made more sense than usrmerge stuff! | 23:13 |
| gnu_srs | Unfortunately nobody was interested :( | 23:14 |
| rrq | what grates most on me is that requirement of having multiple pathnames for the binaries; that they install in one place and can be referred to as if in some other | 23:17 |
| rrq | the quirk in my head wants each "thing" to have a single right pathname and not be *required* to have 2 or 4 pathnames | 23:19 |
| mason | rrq: We brought it on ourselves by not having $PATH variables, linker caches, and similar. | 23:20 |
| rrq | :) | 23:21 |
| rrq | that sounds weery clomplicated | 23:21 |
| mason | heh | 23:21 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!