| parazyd | Happy new year <3 | 01:25 |
|---|---|---|
| Xenguy_ | Hoppy New Year 8 -D | 01:26 |
| mason | LeePen: Random thought crossed my mind. Installation depends on relationships as specified by the repository, even if they're embedded in the packages themselves. It's the repodata that specifies what will be installed. What if we were to shim the Devuan overlays data into repository metadata and leave the Debian packages intact? I haven't thought through the ramifications but the idea popped into my | 03:39 |
| mason | head. | 03:39 |
| mason | s/overlay/override/ | 03:39 |
| mason | bbiab anyway | 03:39 |
| LeePen | mason: Interesting idea. | 11:14 |
| LeePen | I think changing the metadata in the Pacakges files might work. I have a feeling that once a package is installed, apt/dpkg uses the dependencies from the embedded control file. | 11:16 |
| parazyd | mason, LeePen: What are you trying to achieve with modifying metadata? | 12:17 |
| mason | parazyd: We're looking for a way to have Devuan override packages automatically installed along with their base Debian packages. | 16:06 |
| mason | parazyd: The restriction is that we obviously can't change the Debian packages, but maybe this would be enough. Be interesting to understand the implications. Would an "apt --purge auto-remove" then strip the override packages? | 16:07 |
| parazyd | For example? | 16:07 |
| parazyd | I don't understand it still | 16:07 |
| mason | LeePen: I wonder if a package can mark itself as manual on installation somehow. | 16:08 |
| mason | parazyd: LeePen put up a couple examples in yesterday's meeting. I'll find the links. | 16:08 |
| mason | parazyd: https://git.devuan.org/LeePen/debian-config-override https://hindley.org.uk/~mark/debian | 16:09 |
| fsmithred | parazyd, one example is pulseaudio, which needs one line in the config file either commented or uncommented for you to get sound | 16:10 |
| mason | LeePen: If marking as manual works (or if there's a better idea) then the question might become, what happens on upgrade? Whose dependencies are used? I'd assume those from the repository, but it's worth a cogitate. | 16:10 |
| parazyd | You can write apt hooks | 16:11 |
| fsmithred | so rather than fork pulseaudio, we can make a dpkg-divert package to substitude the config file | 16:11 |
| parazyd | It is possible, yes | 16:12 |
| parazyd | This: https://debathena.mit.edu/config-package-dev/ | 16:13 |
| mason | parazyd: The interesting question is how to give them to a user who wants a package but doesn't know they need a Devuan override. | 16:14 |
| parazyd | Maybe create apt hooks and inform them | 16:14 |
| mason | parazyd: Create apt hooks where? | 16:15 |
| mason | parazyd: This is for Debian packages we don't want to fork. | 16:15 |
| parazyd | On the system, with some config package (perhaps devuan-baseconf) | 16:15 |
| parazyd | https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/ | 16:16 |
| fsmithred | shit, we finally got rid of devuan-baseconf | 16:16 |
| parazyd | fsmithred: Doesn't matter, could be anything really | 16:16 |
| parazyd | Then with this said hook you can check if $package is installed and inform the user accordingly. | 16:16 |
| mason | parazyd: Hm. Is this a hook like what apt-listchanges uses? | 16:17 |
| parazyd | I'm not sure what apt-listchanges uses | 16:17 |
| parazyd | But you can set this up however you want (see link above) | 16:17 |
| mason | Yeah, reading that now. | 16:18 |
| parazyd | Whatever you do, don't change existing package metadata as it breaks reproducibility and reproducible builds. | 16:18 |
| parazyd | Like, changing the control file of the .deb or something. | 16:18 |
| mason | Hm, the hook would need to modify the request in-flight if we do it that way, to be maximally effective. | 16:19 |
| parazyd | What? | 16:19 |
| mason | Hm, the hook would need to modify the request in-flight if we do it that way, to be maximally effective. | 16:19 |
| mason | But yeah, we don't want to change the actual Debian package. | 16:19 |
| mason | Hence the notion of changing repository metadata. | 16:19 |
| parazyd | Anything that you do in these contexts should never be silent | 16:20 |
| parazyd | As it makes debugging difficult | 16:20 |
| mason | A pre- or post-command action that just prints a few package names to screen along with a note that they're needed will probably be ignored by most folks, and it'd probably have to sanely interact with graphical package managers - not sure what those do. | 16:21 |
| mason | I think changing dependencies in the respository is the cleanest idea so far, but this is I want it hashed out in public. | 16:21 |
| parazyd | What repository? | 16:22 |
| mason | Devuan's /merged repository, in this case. | 16:24 |
| parazyd | Changing the Packages.gz files? | 16:25 |
| parazyd | And package metadata in them? | 16:25 |
| parazyd | Scary | 16:25 |
| mason | Yes. | 16:25 |
| parazyd | Doesn't sound like a good idea at all | 16:25 |
| mason | Sure it does. | 16:26 |
| parazyd | Why? | 16:26 |
| mason | Anyway, you should come to the meetings. We were struggling to find a clean solution yesterday. | 16:26 |
| mason | This one occurred to me well after the meeting ended. | 16:26 |
| parazyd | We can speak about this here as well. | 16:26 |
| mason | Why is it a good idea? Because without it, users will be installing known-broken systems. We're seeking a way to prevent this automatically. | 16:27 |
| parazyd | Then fork the entire package. | 16:27 |
| mason | Excellent. That *is* the better idea. Which packages are you adopting? | 16:27 |
| parazyd | Modifying repository metadata without any reference is crazy and makes repositories nondeterministic. | 16:28 |
| mason | As you saw in the meeting notes, that's just what I suggested we might have to do. I'm glad we're on the same page. | 16:28 |
| parazyd | mason: I'll adopt any package necessary. I'll go as far as writing software to keep track with changes automatically. | 16:28 |
| mason | Nah, it's quite a reasonable idea. But it wants testing. | 16:28 |
| parazyd | Just give me a list. | 16:28 |
| mason | Come to the meetings and voice your opinion. I think we need to plan on forking packages. | 16:29 |
| parazyd | I can voice my opinion here as well | 16:29 |
| parazyd | As I am | 16:29 |
| parazyd | At least it's more public, if anything. | 16:29 |
| mason | We publish the meeting notes. They're quite public. | 16:30 |
| parazyd | Not my point | 16:30 |
| parazyd | fsmithred: Did you already do any config-package-dev override packages? | 16:31 |
| fsmithred | there's cryptsetup-modified-functions that diverts /lib/cryptsetup/cryptdisk-functions | 16:32 |
| fsmithred | for beowulf | 16:32 |
| parazyd | From antix? | 16:32 |
| fsmithred | yeah, I forked it | 16:32 |
| parazyd | And did you look how this gets installed in antix? | 16:33 |
| fsmithred | no, I didn't | 16:33 |
| mason | How does Antix do it? | 16:34 |
| parazyd | We can ask them | 16:34 |
| fsmithred | yeah, I always assumed it required a manual install | 16:35 |
| LeePen | parazyd: Yes my POC package https://git.devuan.org/LeePen/debian-config-override uses config-package-dev | 17:45 |
| fsmithred | I couldn't get the screen reader to work on the desktop or lightdm screen. I upgraded to chimaera, and it just works. | 21:55 |
| golinux | That's good news. Have to talked to Gregory? | 22:02 |
| fsmithred | no | 22:03 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!