IRC channel logs
2023-11-01.log
back to list of logs
<gnu_srs>youpi: The latest problem occurring with Hurd packages now is dbus (in addition to hurd itself and init-system-helpers) requiring usrmerge/usr-is-merged. <gnu_srs>Can we create +hurd package removing dependencies on these packages, i.e. no /usr aliasing. WDYT? <gnu_srs>I'm discussing with Devuan people now to establish a Devuan GNU/Hurd port. <gnu_srs>If we could revert the Debian changes and publish in unreleased that would not be needed! <youpi>I don't think it's worth pursing such a divergence from debian <youpi>we've been there already with the converse: /usr being a symlink to / <youpi>that brings headaches all around <gnu_srs>I know about the failed GNU/Hurd effore to symlink /usr to /. <gnu_srs>Nevertheless, Guix don't suffer the merged /usr problems, so why not try (outside Debian if necessary)? <youpi>because that doesn't bring any technical benefit? <youpi>you're making the story upside down... Debian was the last one still not using merged /usr <gnu_srs>Many people don't wan merged /usr. Why should they be forced onto it?? <youpi>and Debian using merged-usr doesn't prevent other distributions from doing things otherwise <youpi>we're not changing the hurd source in any way, for instance <gnu_srs>I thought GNU/whatever is about choice, not force like M$or Apple" <youpi>? no, GNU is not about choice <youpi>and debian choosing merged-usr does *not* mean other distributions can't do otherwise <youpi>but we'd better make debian gnu/hurd align on debian gnu/linux <youpi>otherwise it's useless headaches <youpi>we already have enough of them <gnu_srs>and if people want something else they should not be hindered to make changes, right! <youpi>and if you really properly look at things, they won't need changes in the debian/ bits <youpi>again: we're not changing the upstream source habits <youpi>that would make upstream software uninstallable on non-merged-usr <gnu_srs>The problem is not upstream it is Debian! <youpi>how can debian be a problem for other distributions? <gnu_srs>Debis forcing merged /usr on their users (including Hurd)! <youpi>then users can switch to another distribution <gnu_srs>OK, so changing Hurd packages adding +hurd is no way forward? <gnu_srs>I proposed to e.g. remove the usr-is-merged dependency for dbus and create a +hurd version, 1.14.10-3+hurd1 like Devuan does. <youpi>gnu_srs: why publishing it in debian unreleased? <youpi>devuan can have its own unreleased <youpi>I don't plan to spend time on having a non-merged-usr alternative in Debian GNU/Hurd <youpi>and thus I don't plan to spend time on uploading patched packages (which would have to be re-done for each new version!) to debian unreleased just for non-merged-usr support <gnu_srs>Your opinion is perfectly clear, thanks! <gnu_srs>Nevertheless Guix does not suffer from merged /usr problems, right? <youpi>Debian GNU/Hurd doesn't suffer more from merged /usr than Debian GNU/Linux does <gnu_srs>Ok, I'll try to convince Devuan people to help out here. <youpi>Debian GNU/Linux will handle it <gnu_srs>Devuan GNU/Linux does not suffer from the merged /usr problems either, like Guix. <gnu_srs>And I'll convert and upgrade all my hardware boxes to Devuan to avoid the Debian mess. <gnu_srs>It is very unfortunate that you are a Debian fan, more than an upstream person :( <youpi>I'm not an upstream person either <youpi>I just manage where I think my time will be best spent <youpi>people decided to go on merged-usr <youpi>personally, I haven't seen any on my boxes <youpi>so apparently I don't need to care <youpi>really, the merged/non-merged-usr is bikesheding at some point <youpi>we have more important things to work on