17:00:36 <geppetto> #startmeeting fpc
17:00:36 <zodbot> Meeting started Thu Jan 20 17:00:36 2022 UTC.
17:00:36 <zodbot> This meeting is logged and archived in a public location.
17:00:36 <zodbot> The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:36 <zodbot> The meeting name has been set to 'fpc'
17:00:36 <geppetto> #meetingname fpc
17:00:36 <zodbot> The meeting name has been set to 'fpc'
17:00:36 <geppetto> #topic Roll Call
17:00:56 <decathorpe> My body is here, but my spirit wanders.
17:01:00 <mhroncok> .hello churchyard
17:01:01 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:01:07 <geppetto> #chair decathorpe
17:01:07 <zodbot> Current chairs: decathorpe geppetto
17:01:12 * GwynCieslasheher here
17:01:13 <geppetto> #chair mhroncok
17:01:13 <zodbot> Current chairs: decathorpe geppetto mhroncok
17:01:18 <geppetto> #chair GwynCieslasheher
17:01:18 <zodbot> Current chairs: GwynCieslasheher decathorpe geppetto mhroncok
17:01:27 <tibbs> Hello.
17:01:31 <geppetto> #chair tibbs
17:01:31 <zodbot> Current chairs: GwynCieslasheher decathorpe geppetto mhroncok tibbs
17:03:35 <carlwgeorge> .hi
17:03:39 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
17:04:09 <geppetto> #chair carlwgeorge
17:04:09 <zodbot> Current chairs: GwynCieslasheher carlwgeorge decathorpe geppetto mhroncok tibbs
17:04:19 <geppetto> hey everyone
17:04:32 <geppetto> #topic Schedule
17:04:36 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/MTQIZVQWXXBTE2GCN2J2RTH3CNXPFGYN/
17:05:47 <mhroncok> I'd like to add https://pagure.io/packaging-committee/pull-request/1144
17:06:26 <decathorpe> I'd like to add https://pagure.io/packaging-committee/pull-request/1124
17:06:29 <geppetto> Yeh, was just about to do that … and 1152
17:06:42 <geppetto> #topic  #1144 Weak dependencies on subpackages MUST NOT be fully versioned
17:06:43 <tibbs> I thought I tagged 1152 but when I just looked it wasn't tagged.
17:06:48 * geppetto nods
17:07:07 <tibbs> I have to say I don't fully understand the implications of 1144.
17:07:41 <mhroncok> I can explain
17:07:41 <decathorpe> I think it is to make sure the ExcludeWeakAutoInstallDetectWhateverFooBar feature in dnf works as expected
17:07:55 <mhroncok> yes
17:08:13 <decathorpe> because if you fully version the Recommends, it will count as a new dependency every time?
17:08:14 <mhroncok> the things is, if a package recommends foo-subpackage = 1.2-5.fc36
17:08:37 <mhroncok> and that recommendation is already broken, a new build will recommend foo-subpackage = 1.2-6.fc36
17:08:48 <mhroncok> and for dnf, that is a different requirement -- a new one
17:09:08 <mhroncok> so it will install it again, even with ExcludeWeakAutoInstallDetectWhateverFooBar
17:09:35 <tibbs> I have to say, that sounds like a DNF bug more than anything.
17:09:36 <mhroncok> while if it only recommends foo-subpackage, the updated build still recommends foo-subpackage amd that is an already knwon dependency
17:09:59 <mhroncok> well, it is not perfect, but it is certainly better than it used to be
17:09:59 <carlwgeorge> is the end goal to not reinstall weak deps that you've explicitly uninstalled?
17:10:07 <mhroncok> yes
17:10:13 <carlwgeorge> nice
17:10:14 <geppetto> I guess this comes from requires … where mixing sub-package versions is generally a bad idea?
17:10:16 <mhroncok> (or excluded)
17:10:36 <mhroncok> yes, people add fully verisoned recommends becasue we say this is a good idea for requires
17:10:59 <geppetto> So do we want a: conflicts: foo-subpackage != %{version}-%{release}
17:10:59 <mhroncok> but for recommends it doesn'T mater. the subpackage usually reverese-requires the main thing anyway
17:11:22 <carlwgeorge> it's a good idea to ensure subpackages get updated if you update the main package, which only matters sometimes
17:11:34 * geppetto nods
17:11:35 <decathorpe> I don't think a full ban is a good idea. But telling people that they SHOULD NOT use fully versioned Recommends unless they really really know what they're doing is fine with me
17:11:38 <mhroncok> if there is no versioned reverse dependency and the package will do creazy stuff with a different subpackage version, than I guess yes
17:11:41 <geppetto> I guess I'm fine with it either way
17:11:44 <tibbs> So I'm curious: if DNF only cared about the package name and not NEVR, would this rule make any sense?  In other words, is there any reason at all for this proposal besides this specific DNF behavior?
17:12:04 <mhroncok> probbaly not
17:12:33 <geppetto> Yeh, it kind of feels like DNF should ignore the version/release reqs. when using that feature
17:12:46 <mhroncok> it ain't gonna happen
17:12:52 <geppetto> lol
17:13:05 <tibbs> Because honestly if it's only because of this specific DNF behavior, it might be worth mentioning that so as not give the impression that there is some deep magic around this instead of what is arguably a DNF bug.
17:13:19 <mhroncok> even getting the dnf people to accept that reinstalling the excluded/removed packages is a bad behavior took years
17:13:22 <GwynCieslasheher> Good idea
17:13:41 <mhroncok> #action mhroncok mention this is to please dnf
17:13:54 <mhroncok> #action mhroncok to explain when conflicts need to be added
17:14:26 <decathorpe> What if you want dnf to treat it as a new weak dependency, in case of emergency?
17:14:52 <mhroncok> Fabio Valentini: use >= CURRENT_EVR
17:15:06 <decathorpe> fair enough.
17:15:09 <geppetto> decathorpe: Don't? … I can't think of a case you'd really need a weak dep. to be considered again
17:15:39 <decathorpe> Just because I can't think of a case doesn't mean that people will find one :)
17:15:48 <decathorpe> *won't fine one
17:15:54 <decathorpe> arghs
17:15:56 <GwynCieslasheher> Humans are funny that way.
17:16:04 <mhroncok> :D
17:16:22 <geppetto> It's not like anyone sane is removing weak deps. anyway … but more like if it was that important when it should really be a requires anyway
17:16:57 <decathorpe> that's true. sorry, I didn't want to derail the discussion
17:16:57 <geppetto> I'm def. fine keeping it as a ban, with the explanations for why
17:17:03 <geppetto> no problem
17:17:47 <geppetto> but if a bunch of you feel strongly it should just be recommends then you should speak up now :)
17:18:05 <geppetto> ugh … recommends policy for recommends
17:18:34 <decathorpe> :ship: it
17:18:59 <tibbs> I guess I'm fine either way, but ngompa's argument does seem at least reasonable.
17:19:24 <carlwgeorge> his example seems like a misuse of recommends imo
17:20:13 <tibbs> Indeed, the most recent comment indicates it's just a way to have something betwixt Recomments and Requires.
17:20:24 <geppetto> #action mhroncok 🚢 it
17:20:44 <geppetto> #topic  #1124 clarifications for Rust Naming and Versioning guidelines
17:20:47 <tibbs> tofu it?
17:20:51 <geppetto> This hasn't changed much recently
17:21:15 <geppetto> decathorpe: I guess it's read to just merge, was there anything you wanted to discuss?
17:21:31 <geppetto> *ready
17:22:30 <decathorpe> it's fine
17:23:13 <tibbs> Note: It's easier if you look at the commits separately, since the second one mostly seems to be cleanups while the first has the substantive change.
17:23:15 <geppetto> I guess just merge it then? You thought all the concerns where dealt with?
17:23:39 * geppetto gives 🚢's to everyone
17:23:48 <tibbs> +1
17:24:00 <tibbs> Thanks for the tofu?
17:24:08 <geppetto> haha
17:24:26 <geppetto> unicode says "ship" for that character
17:24:34 <geppetto> #topic  #1152 Add BLAS/LAPACK guidelines
17:25:06 <mhroncok> I have not yet read that
17:25:26 <geppetto> Yeh, me either
17:25:30 <tibbs> I merged 1124.
17:25:42 <tibbs> Well, rebased and merged.
17:25:58 <geppetto> A quick look suggests I'm going to +1 a merge on it
17:26:14 <geppetto> While knowing not much about BLAS/etc.
17:26:25 <tibbs> I don't have a problem with the lapack stuff but it I wonder if there are other subject experts that might want to comment.
17:27:51 <mhroncok> I'll have a look
17:28:13 <mhroncok> I am not an expert on blas, but I've dealt with this topic when flexiblas was introduced to fedora
17:28:58 <geppetto> cool
17:29:32 <geppetto> You want to wait and have a look now, or wait until next week?
17:29:50 <tibbs> I have to step out for a few minutes.
17:30:02 <geppetto> We don't have anything else for this week anyway
17:30:19 <mhroncok> gimme 5 minutes
17:31:00 * geppetto nods
17:36:49 <mhroncok> added some feedback there, will wai to for response
17:36:55 <mhroncok> otherwise +1 generally
17:37:47 <geppetto> nice, let's mhroncok steer the 🚢
17:37:51 <GwynCieslasheher> Yeah, looks ok
17:38:08 <geppetto> #topic Open Floor
17:38:18 <geppetto> Anything else we need to talk about this week?
17:39:08 <tibbs> We will eventually have to do 1150 but maybe not this week.
17:39:24 <tibbs> I tagged it.
17:40:19 <geppetto> .fpc 1150
17:40:20 <zodbot> geppetto: Issue #1150: request for clarification wrt. base version / compat package naming - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1150
17:40:45 <GwynCieslasheher> FTR I've already got the package that inspired the issue in rawhide.
17:41:21 <GwynCieslasheher> But I'd love this to be settled before I start compat-libgda.
17:41:42 * geppetto nods
17:42:00 <decathorpe> Yeah, sorry about the confusion. It would be great to at least recommend something
17:42:38 <tibbs> I mean, technically it's settled but I'm not sure if people want the guidelines to be more explicit or if they actually want more restrictions.
17:42:40 <GwynCieslasheher> I think those of us in this room sort of intuitively grok the nuances here, we just need to express it clearly.
17:42:48 <GwynCieslasheher> Right.
17:43:08 <decathorpe> usually it's "package without suffix is the latest one", but for GNOME packages, it's almost always the other way round (i.e. libhandy 0.90 and libhandy1, libsoup 2.x and libsoup3, ...)
17:43:36 <GwynCieslasheher> And then those without a no-suffix version, gtk2,3,4...
17:43:54 <tibbs> Right now it's always "what the packager decides is best".
17:43:54 <carlwgeorge> imo, the unversioned should be latest, or every package should be versioned like gtk2/gtk3/gtk4
17:44:04 <decathorpe> this led to the especially awkward situation of libhandy-without-suffix then being updated to 1.x and libhandy1 being retired :)
17:44:18 <GwynCieslasheher> Eeeeew.
17:44:36 <tibbs> For the record, it was "unison" that led to the current guideline, I believe.  Since different versions are completely incompatible.
17:44:49 <decathorpe> GNOME people always do their own thing :shrug :
17:44:54 <carlwgeorge> yup
17:44:59 <GwynCieslasheher> Like they share the name but that's it.
17:45:18 <decathorpe> yeah, libhandy-1 and libhandy-0 were completely parallel-installable too
17:45:34 <carlwgeorge> i think the "unverisoned not the latest" scenario should not be allowed, at least for the srpm
17:45:50 <carlwgeorge> that would be compatible with how python works now i believe
17:45:52 <tibbs> And I quite disagree.
17:46:27 <mhroncok> I still think the unversione dversion must be the most important one
17:46:32 <mhroncok> not neccessarily the latest
17:46:38 <tibbs> But I agree that it should be the normal case for the unversioned one to be something close to latest for some definition of "latest".
17:46:57 <mhroncok> if most of the distro runs on the older one, it's fine if the latest and greates bleeding edge is verisoned
17:47:06 <mhroncok> > for some definition of "latest"
17:47:08 <mhroncok> this
17:47:15 <carlwgeorge> "most important" is way too subjective to write into guidelines, at that point it's just "use your best judgement" i.e. "do whatever you want"
17:47:29 <mhroncok> I agree :D
17:47:48 <carlwgeorge> fedora routinely does things that most other distros aren't doing yet
17:47:49 <mhroncok> ideally, if multiple versions are to be kept around for a while, I think we should version them all
17:47:53 <geppetto> The problem with most of the distro. running on an older versoin is that is unlikely to stay true
17:48:08 <carlwgeorge> mhroncok yup, that's what i was saying
17:48:25 <mhroncok> I said "most of the distro" as in "most of the Fedora packages"
17:48:38 <carlwgeorge> ah
17:48:45 <mhroncok> yeah and once it no longer is tru you need to rename, which is horrible
17:48:52 <decathorpe> Can we at least make a recommendation for "unversioned = latest, unless there's a good (for some definition of "good") reason to do otherwise"?
17:48:59 <mhroncok> especially when you thne have a cross-branch cross-component matrix of things
17:49:09 <mhroncok> that's why we now version all python components
17:49:52 <mhroncok> I can live with that, as long as we also allow verisoning them all
17:50:05 <GwynCieslasheher> Right.
17:50:23 <carlwgeorge> we could say that in rawhide, unversioned == latest, and stable branches are allowed to lag behind this
17:51:10 <decathorpe> doesn't that just make it worse, where the same package has different names in different branches?
17:52:28 <carlwgeorge> i think it's less bad than the confusion of unversioned != latest in rawhide
17:52:31 <geppetto> Yeh, I'd rather say unversion always = latest … and if you need a bleeding edge just version everything
17:53:19 <decathorpe> I don't even necessarily want this to be a hard rule, but right now, the guidelines don't say anything about this, so it leads to confusion
17:54:07 <carlwgeorge> is there a specifc drawback to making the rule "unversioned == latest or version everything"?
17:54:13 <geppetto> Sure, but I think the worst case is renaming things … so if we say anything I'd want to lean heavily towards making renames very rare
17:54:42 <mhroncok> unversioned == latest vs stable release is hard
17:55:14 <mhroncok> you would need to rename the package on stable branch just becasue you want to also introduce a newer ("nondefault") version
17:55:36 <geppetto> mhroncok: at that point version everything … works for debian
17:55:45 <geppetto> ¯\_(ツ)_/¯
17:56:19 <decathorpe> (well, that's also the case for "unversioned = latest", leading to foo-X being renamed to fooX when foo-Y is included)
17:56:36 <decathorpe> so the rename-shuffle happens regardless
17:56:47 <mhroncok> rename-shuffle is PITA
17:57:12 <carlwgeorge> yeah we should aim for long term making renames rare, short term there will be expected churn no matter what we decide for the guidelines
17:57:12 <decathorpe> it is. keeping it to a minimum is a good idea ..
17:57:35 <GwynCieslasheher> Yeah, that's unavoidable.
17:58:25 <geppetto> Do we want to suggest that any package that is likely to need an older/newer compat. version should move to version everything then?
17:58:44 <geppetto> I'm … good with that, I think.
17:58:45 <carlwgeorge> yeah i think so
17:59:22 <mhroncok> at least for component names
17:59:23 <decathorpe> versioning everything would make Rust packaging very awkward
17:59:24 <carlwgeorge> if an upstream is routinely making incompatible major versions, gtk seems like the example to follow.  i'm thinking a guideline along the lines of "if you want to make libfoo3 when libfoo is still version 2, should rename libfoo to libfoo2 and only do versioned going forward"
17:59:49 <mhroncok> I don't think we can make a good set of rules here
17:59:58 <carlwgeorge> decathorpe: rust pkgs seem to do a good job of keeping unversioned on latest
18:00:06 <carlwgeorge> largely thanks to you :D
18:00:22 <decathorpe> carlwgeorge: that's because they're designed to work that way
18:00:30 <mhroncok> it's easy to be conistent, if it's just you :D
18:00:48 <GwynCieslasheher> And if people started out doing something coherent.
18:01:05 <carlwgeorge> what i'm saying is preference to unversioned latest, if you want to do something else strongly consider version everything
18:01:07 <geppetto> So … we just get decathorpe to do everything?
18:01:30 <mhroncok> I am somewhat OK with "preference to unversioned latest" on rawhide
18:01:37 <mhroncok> but I am not sure about stable releases
18:01:49 <decathorpe> I'm just saying that for projects like nix, which release incompatible versions every few weeks, keeping around nix0.16, 0.17, 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, creating a new repo for every version is unreasonable burden to updating the package
18:02:08 <carlwgeorge> i don't see an issue with stable release keeping the version scheme they had when that code was rawhide
18:02:35 <decathorpe> > "what i'm saying is preference to unversioned latest, if you want to do something else strongly consider version everything" that sounds reasonable to me
18:02:38 <carlwgeorge> *naming sheme
18:02:42 <mhroncok> carlwgeorge: and do you see a problem upgrading it?
18:03:06 <mhroncok> for rust, it makes sense
18:03:30 <geppetto> decathorpe: We could say version everything, but you are allowed to reuse a single nix distgit repo. if you only have one version in a release?
18:03:30 <mhroncok> but for packages that user install on runtime? consider the newer version will upgrade my thing that needs to remain stable by promise
18:03:57 <decathorpe> no, we have 5-6 different versions at a time, but not necessarily every one
18:04:10 <decathorpe> and which ones you need might change from week to week
18:04:18 <carlwgeorge> mhroncok: the software major version upgrade would happen with the distro upgrade, seems reasonable to me
18:04:21 * geppetto slowly backs away
18:04:42 <decathorpe> geppetto: most people who have looked at the details of Rust packaging have done that
18:05:19 <mhroncok> carlwgeorge: yes, if you follow "stable release keeping the version scheme they had when that code was rawhide"
18:05:32 <mhroncok> but do we allow not keeping it?
18:05:49 <mhroncok> do we allow maintaing unversioned == latest acrosss stable releases?
18:06:07 <carlwgeorge> i'm thinking no, but could be convinced otherwise with some good examples
18:06:17 <mhroncok> because I think we shouldn't (except for rust etc.) as it breaks things unless you design your obsoletes quite carefully
18:06:43 <decathorpe> yeah, we're basically only using virtual Provides, never the actual package names
18:07:14 <mhroncok> and users don't keep the devel packages installed around as if they could use them
18:07:25 <mhroncok> so we are not breaking their API strictly speaking
18:07:45 <mhroncok> anyway, the recommendation that unversioned == latest would only apply to rawhide
18:08:06 <mhroncok> and now you also need to explain what to do with the rest of the releases
18:08:11 <geppetto> Well one thing I'm sure of is that we are coming up on 10 mins. overtime, and I'm pretty sure we aren't going to solve this in the next couple of minutes
18:08:21 <decathorpe> probably not. :)
18:08:22 <mhroncok> we aren't
18:08:33 <mhroncok> let's propose a set of rules asynchronously
18:08:39 <geppetto> +1
18:08:45 <mhroncok> *recommendations
18:08:49 <decathorpe> sounds good
18:08:59 <geppetto> 1150 got tagged with meeting, so it'll be here next week.
18:09:21 <decathorpe> thanks.
18:09:55 <geppetto> Ok, see you then … feel free to add comments to 1150 and we'll see what we can do
18:10:02 <geppetto> #endmeeting