[01:17] <Soni> how do you keep apt from autostarting freshly-installed services, in particular network-enabled ones like lighthttpd, bitlbee, quassel, transmission-daemon, etc, before you have a chance to configure them?
[01:38] <rbasak> Soni: look up "policy-rc.d"
[01:39] <rbasak> Example: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html#parameter-policy_rc_d
[01:39] <rbasak> IMHO, setting it to 101 should be the default in tools like ansible, and it's a bug in these tools that it's not.
[01:39] <rbasak> But at least you can do it properly with options like that
[06:00] <lordievader> Good morning
[10:01] <Soni> rbasak: how does that help someone installing stuff?
[10:18] <P-NuT> I am looking at using Modsecurity on ubuntu, but it seems a faff to use it with NGINX, whereas it seems easier to use with apache. I was wondering if anyone had any personal stories of running either in production that could advise.
[11:38] <J_Darnley> Does anyone know where might be the best place to ask a deep packaging question?  Specifically about giving an optional dependency on a minimum version of another package.
[12:09] <TJ-> J_Darnley: you mean in the debian/control Recommends: or "Depends:" ?
[12:33] <pirx> i am trying to upgrade a server from 18.04 to 20.04, and the upgrade fails (could not calculate upgrade). i see in /var/log/distupgrade/apt.log that its something with a package called python-is-python2, which kinda seems to be installed (or held??), but isnt according to dpkg etc. i have tried to purge it anyway, and install it even, but its just not to be found...
[12:34] <pirx> can i manually look into this somehow? like, where are the DBs/lists of what packages the system possibly thinks it has?
[12:34] <pirx> i'd like to just nuke-purge it somehow and do the upgrade, and hope that 20.04 will have all the packages it needs:)  (also, i just bumped the server from 16.04 to 18.04)
[12:34] <pirx> i see this in apt.log: https://pastebin.com/67teZ9ZU
[12:35] <pirx> now i have looked around in the files in /var/lib/apt/lists/ and python-is-python2 only seems to exist in 20.04
[12:49] <J_Darnley> TJ-: yes one of those control fields
[12:53] <J_Darnley> Should I just ask my question here?
[13:17] <Ussat> FWIW I never "upgrade" prod servers like that, I always build new,  config w/ansible. I will upgrade a desktop I dont care about but thats it
[13:17] <Ussat> build new in parallel, take downtime, swap names/ip
[13:18] <Ussat> done
[13:36] <rbasak> !ask | J_Darnley
[13:36] <ubot3> J_Darnley: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[13:40] <J_Darnley> Okay then
[13:43] <J_Darnley> I have a package X in which a user might use 1 of 3 options.  That option requires a minimum version of another package Y.  How can I ensure that the user can't install my package when they have a version of Y less than a specific version?
[13:55] <rbasak> Put "Breaks: X (< whatever)" in Y.
[13:55] <rbasak> No sorry, that's backwards.
[13:56] <rbasak> I'm not sure I follow. Maybe "Depends: Y (>= version) | Y' | Y''"?
[13:56] <rbasak> (in X)
[13:58] <J_Darnley> It isn't a fixed dependency though.  Users of X don't need Y unless they use the Y option.
[13:59] <J_Darnley> Do the lower levels of package relationships do strict version checking?  Could it be a recommends?
[13:59] <J_Darnley> What do you mean by Y' and Y''?
[14:00] <rbasak> Your alternatives to Y
[14:00] <rbasak> Maybe Breaks is right then, but it needs to be the other way round.
[14:00] <rbasak> In X, "Breaks: Y (< version)".
[14:00] <rbasak> That will prevent X and older Y being installed together.
[14:01] <rbasak> However, if older Y is installed and the user installs X, and newer Y isn't available, apt will I think resolve by removing Y.
[14:01] <rbasak> It's an odd request though. Which package is this?
[14:01] <J_Darnley> Oh I forgot to say I think this is always though dpkg
[14:02] <J_Darnley> It is my company's software
[14:02] <J_Darnley> And we don't list the alternatives in depends (yet)
[16:01] <teward> J_Darnley: just because it's your company's software doesn't mean it can't be apt installed (`sudo apt install ./package_1.2.3-amd64.deb` for example)
[16:01] <teward> and you really should be avoiding doing direct `dpkg` installations and just call the local debian files via `apt install` for dependency resolution.
[16:01] <teward> because `dpkg` doesn't have the dependency knowledge as much as you think it would ;)
[16:01] <teward> hence why rbasak suggests adjusting the package with the alternatives, breaks, etc.
[16:02] <J_Darnley> How am I supposed to keep track of the innumerable ways to install debian packages?
[16:02] <teward> not relevant to this conversation and rbasak's suggestions (which are critical to packaging policy for Debian packages regardless of how you install the package)
[16:03] <sdeziel> J_Darnley: the simple way is to always use apt
[16:04] <J_Darnley> Then what is apt-get?
[16:04] <mybalzitch> one of the  tools people used before they unified all the apt stuff into just apt
[16:05] <teward> J_Darnley: apt-get is the older tool, apt is the more modern unified tool that does more than apt-get and handles a few things better
[16:06] <teward> dpkg is really low level compared to apt-get and apt, and you should use `apt` where possible.
[16:06] <teward> (apt and apt-get both call dpkg, but dpkg is the low-level thing that doesn't really handle all the dependency resolution stuff)
[16:07] <rbasak> Except for scripting. apt isn't suitable to use from scripts because it doesn't have a stable interface
[16:08] <J_Darnley> I have noticed that message from apt.
[16:08] <rbasak> See "SCRIPT USAGE AND ..." in apt(8)
[16:11] <J_Darnley> If I want to read about what I can do with `apt install` do I need to read the `apt-get` manpage?  Or just a newer ubuntu release with a better one?
[16:34] <leftyfb> rbasak: your last point about apt and scripting, have you seen any indication that that is being actively worked on? It's been more than a few years now
[18:06] <kinghat> whats the process like of getting recent zfs on server?
[18:13] <kinghat> maybe it will be backported in aug? https://www.reddit.com/r/Ubuntu/comments/k47ghh/will_openzfs_200_be_available_in_the_ubuntu_2004/ge8l8wh
[18:13] <sarnold> maaaaybe. last I heard the utils had to match the kernel closely
[18:13] <sarnold> I don't know how we intend to handle that large of a backport
[18:15] <sarnold> kinghat: I've seen https://launchpad.net/~jonathonf/+archive/ubuntu/zfs referenced before, but never tried it myself
[18:17] <kinghat> ya i saw that too. maybe ill just give it gzip compression
[18:33] <rbasak> leftyfb: I don't think there's anything to work on. apt-get provides a stable CLI and isn't going away, and as the manpage says, all facilities provided by "apt" are available through the previously existing commands.
[18:33] <rbasak> "apt" is just a CLI-user-friendly wrapper that has defaults that might change; that's all.
[18:35] <leftyfb> it would be nice to take advantage of "the more modern unified tool that does more than apt-get and handles a few things better" in scripting
[18:40] <rbasak> I'm not sure where you got that idea. Did you read the manpage section I referenced above?
[18:45] <leftyfb> rbasak: the quoted comment was from teward.
[18:45] <teward> i was pinged
[18:45] <teward> rbasak: that's my fault, apologies
[18:45] <teward> but for the purposes of installing a .deb package as an end user directly on the command line I'd suggest `apt` over `apt-get` but either work
[18:46] <teward> i just would shy away from using `dpkg` directly unless I had no choice.
[18:48] <leftyfb> I didn't know apt was only meant to be a wrapper for apt-get/apt-cache and never meant to replace them. I thought it was a means to an end, incorrectly apparently
[20:07] <teward> rbasak: if apt was not meant to replace apt-get then we need to do some work on apt-get
[20:08] <teward> because apt lets you accept and check things triggered by apt-secure, in case someone changes something on the repository side of things (i.e. third party repo names get changed but are still otherwise identical)
[20:08] <teward> or better documentation on fixing that via apt-secure calls or such
[21:58] <rbasak> teward: I'm pretty sure it's just default options that can all be tweaked