16:03:53 <geppetto> #startmeeting fpc
16:03:53 <zodbot> Meeting started Thu Oct  5 16:03:53 2023 UTC.
16:03:53 <zodbot> This meeting is logged and archived in a public location.
16:03:53 <zodbot> The chair is geppetto. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:03:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:53 <zodbot> The meeting name has been set to 'fpc'
16:03:53 <geppetto> #meetingname fpc
16:03:53 <zodbot> The meeting name has been set to 'fpc'
16:03:53 <geppetto> #topic Roll Call
16:04:21 <michel-slm> .hello salimma
16:04:22 <zodbot> michel-slm: salimma 'Michel Lind' <michel@michel-slm.name>
16:04:25 <decathorpe> .hi
16:04:26 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
16:04:32 <geppetto> #chair decathorpe
16:04:32 <zodbot> Current chairs: decathorpe geppetto
16:04:38 <decathorpe> sorry, needed to install an IRC client on a fresh Fedora install first :D
16:05:16 <geppetto> No worries, I was doing 3 different things and almost missed the meeting
16:05:48 <michel-slm> decathorpe: I put my irc client on a tilde shared account for this reason :)
16:05:55 <michel-slm> running inside tmux :P
16:07:03 <decathorpe> I need to learn about those things at some point I think ...
16:07:55 <carlwgeorge> .hi
16:07:56 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
16:08:06 <geppetto> I recently learnt tmux from a fedora article … was pretty easy
16:08:10 <geppetto> #chair carlwgeorge
16:08:10 <zodbot> Current chairs: carlwgeorge decathorpe geppetto
16:08:15 <dcavalca> .hi
16:08:16 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <davide@cavalca.name>
16:09:03 <geppetto> decathorpe: Actually RH article: https://www.redhat.com/sysadmin/introduction-tmux-linux
16:09:27 <decathorpe> thanks! I'll take a look :)
16:12:55 <geppetto> tibbs: You around, or is it still September there?
16:14:06 <geppetto> #topic Open Floor
16:14:13 <geppetto> .fpc 1307
16:14:14 <zodbot> geppetto: Issue #1307: Clarification needed regarding the naming of Golang packages - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/1307
16:14:33 <geppetto> It's worth taking a look at this and talking about it for anyone not already involved.
16:14:50 <geppetto> I'm pretty sure I'm fine with just changing it so that what go is doing is fine.
16:14:58 <geppetto> it == the policy.
16:15:54 <decathorpe> my opinion: Go packages have been using their own set of consistent rules for packaging multiple versions, so I think documenting this as an "acceptable" pattern would be good - if not in general, then at least for Go packages.
16:16:36 <geppetto> It probably reads a little better to not have the last separator, but not enough to mass change a bunch of packages … and it's probably easier to deal with automatically anyway.
16:16:56 <decathorpe> yes, "Name" tag for those Go packages is written by a macro
16:16:58 <geppetto> Would be nice to get tibbs view, and how much he cares about it though
16:17:16 <decathorpe> changing the rules would involve changing that macro, which would break all existing packages using that pattern
16:17:48 <geppetto> yeh, would realistically need a new macro and then migrate each package to use obsoletes to rename.
16:18:00 * geppetto shudders
16:18:15 <decathorpe> I don't think doing this for 10² - 10³ packages would be worth it
16:18:43 <decathorpe> for better or for worse, it looks like this is here to stay, if only by inertia :D
16:19:04 <michel-slm> for the meeting notes, what would it look like with and without the last separator?
16:19:15 <geppetto> Yeh, I also see "gedit-color-schemes-gtksourceview-2" … so not just golang.
16:19:34 <decathorpe> yeah, the current guidelines haven't always been follwed to the letter
16:19:54 <michel-slm> oh so the version is separated by a dash? that's actually quite nice, though yeah, non standard
16:20:24 <decathorpe> michel-slm: the package for go import path "k8s.io/klog/v2" is currently "golang-k8s-klog-2", but guidelines would mandate "golang-k8s-klog2"
16:20:44 <geppetto> decathorpe: To be fair I _think_ it's much less packages that actually have a -2, -3 or -4 suffix (maybe 20ish).
16:20:45 <decathorpe> though arguably, using a dash is consistent here, since it's a separator that comes from the *import path*, not really from the version
16:21:01 <decathorpe> geppetto: true, maybe I overestimaged things :)
16:21:03 <michel-slm> true but if you follow that consistently it will be -v2 :)
16:21:24 <decathorpe> don't ask me. the rules for %goname are weird
16:21:29 <carlwgeorge> yeah i was thinking -v2 would be the time machine fix
16:22:30 * geppetto nods
16:22:33 <decathorpe> "golang-github-oschwald-geoip2" is the package name for "github.com/oschwald/geoip2-golang" (because the macro also strips "-go" and "-golang" from parts of the path ...
16:22:52 <decathorpe> so doing the "-2" suffix isn't the worst thing that macro does
16:23:08 <carlwgeorge> i'm not positive but i'm pretty sure the current naming guidelines predate the current golang guidelines, meaning the latter was implemented incorrectly from the start, doing their own thing in spite of the naming guidelines
16:23:09 <geppetto> Anyone have anything non-golang naming related?:)
16:23:34 <michel-slm> oh the joy of bikeshedding
16:23:35 <carlwgeorge> i'm not thrilled at how this went down, but i get that renaming lots of packages is work no one is signing up to do
16:23:36 <decathorpe> carlwgeorge: likely true, but also unlikely to change now :(
16:24:26 <decathorpe> geppetto: I have an almost-complete draft for new Rust Packaging Guidelines, where I hope to have the open TODO items addressed soon ... maybe people here can take a look? it's already been trough a few small revisions inside the Rust SIG
16:24:38 <decathorpe> https://hackmd.io/@decathorpe/FedoraRustPackagingGuidelines
16:24:49 <carlwgeorge> lets hope that "do your own thing, get enough inertia so that policy changes to match" doesn't become the standard way to change policy
16:25:08 <geppetto> carlwgeorge: Again, it should be easy for all the golang packages on v1 … so if we want to push back it's probably still viable.
16:25:25 <geppetto> I'm just … not sure I care.
16:25:26 <carlwgeorge> it would require changing the macros right?
16:25:38 <geppetto> carlwgeorge: Yeh
16:25:54 <carlwgeorge> that's where it hits "hard pass" from me lol
16:26:51 <carlwgeorge> lets carve out the naming exception for golang and then never speak of it again (until all golang libs are retired, following the nodejs example)
16:26:52 <geppetto> fair enough 👍
16:27:05 <decathorpe> 😅️
16:29:45 <carlwgeorge> nim's three comments on 1307 are their only pagure.io activity for the past year
16:30:05 <decathorpe> 😶‍🌫️
16:31:30 <carlwgeorge> so i guess the ticket comment should be something along the lines of "we support you in this endeavor, please propose the phrasing as a pr to the naming guidelines"
16:32:15 <geppetto> +1
16:32:37 <decathorpe> +1
16:32:47 <decathorpe> though I suppose it could also just go into the Go guidelines
16:32:59 <carlwgeorge> alternatively, we could say that future packages need to follow the regular rules, but existing packages can stay named how they are
16:33:32 <decathorpe> that would likely be difficult :( it would require implementing two macros (or adding a second mode to the current one)
16:33:39 <decathorpe> and it would also make naming inconsistent
16:35:08 <carlwgeorge> actually now that i think about it, i don't think it would be that bad.  new packages just wouldn't use %goname.  that's already possible for packages that ship a "well known" command.
16:36:06 <michel-slm> if we require new packages to use proper names I guess we can make %goname spit out a warning
16:36:22 <michel-slm> point people to the new macro and say %goname should only be used for legacy packages
16:36:55 <michel-slm> oh, but the spec generator will need to output both or provide a flag, if golang packages are periodically regenerated from scratch like rust packages
16:37:43 <carlwgeorge> i think it's already necessary to change the Name: field when you use the spec generator and want a well known name
16:37:59 <carlwgeorge> the golang guidelines use the example of etcd
16:39:15 <carlwgeorge> yeah it looks like etcd uses all the go macros except %goname https://src.fedoraproject.org/rpms/etcd/blob/rawhide/f/etcd.spec#_38
16:39:49 <decathorpe> it's difficult to figure out Name to be consistent with %goname when not using the macro though
16:39:51 <michel-slm> making the generator handle these cases better would probably help but that's outside FPC's responsibility right
16:40:11 <carlwgeorge> correct
16:40:32 <decathorpe> though I've always been against using %goname for Name - since a change in the %goname implementation can lead to the situation where source package Name != dist-git package name
16:40:44 <carlwgeorge> agreed
16:40:50 <decathorpe> but I digress
16:40:58 * decathorpe also hesitates to mention that he likely wants to ask for a similar syntax "exception" for Rust compat packages in the future
16:41:08 <geppetto> ha
16:41:35 <michel-slm> yeah, the situation where the package has a number at the end *and* we want a compat version of it is confusing to parse
16:41:36 <carlwgeorge> wouldn't keeping the "v" neatly sidestep the issue?
16:42:00 <carlwgeorge> `k8s.io/klog/v2` -> `golang-k8s-klog-v2`
16:42:03 <decathorpe> carlwgeorge: well .. yes, I guess :)
16:42:28 <geppetto> carlwgeorge: yes, but again … time machine
16:42:41 <decathorpe> well, we can give these two options in the ticket
16:43:04 <carlwgeorge> probably best to wait on tibbs's input anyways since he raised the issue in the first place
16:43:05 <decathorpe> either document this one or switch from -X suffix to -vX
16:45:14 <carlwgeorge> i'm leaning towards banning the use of %goname, for the reason decathorpe mentioned, and to give us full flexibility on what the name should be without feeling like we're bound by the macro implementation
16:45:59 <decathorpe> then again, I also said that making consistent Names for Go packages without %goname is hard
16:47:26 <carlwgeorge> we could add a note that go2rpm does it slightly incorrectly, and to pull the last separator (or put the v back).  that way people still get the name computed, with just a slight manual adjustment afterwards.
16:48:23 <decathorpe> that works for me
16:49:48 <michel-slm> one "fix" in the transition would be to have go2rpm use %goname to spit out the actual name, and write that down in the spec, right
16:50:34 <decathorpe> yup
16:50:42 <carlwgeorge> most of the time it doesn't include the version, right?  what triggers having the version suffix?
16:51:00 <decathorpe> having the import path looks like "foo.bar/one/two/v2
16:51:49 <decathorpe> i.e. "pull in dependency foo.bar/one/two, but only version 2, not any later or earlier version"
16:52:43 <michel-slm> I... don't have much love for this golang semantic
16:52:53 <carlwgeorge> same
16:53:05 <decathorpe> it's not that different from Rust specifying a dependency on `syn = "2"`
16:53:23 <decathorpe> just ... that Go doesn't have a namespace for packages, it only has remote git repositories
16:54:03 <carlwgeorge> is the v2 used in the import path inside the code also?
16:54:15 <carlwgeorge> or just in the go.mod file or whatever?
16:55:08 <decathorpe> it's in the code too
16:55:31 <decathorpe> that works independently of the Go module system
16:55:40 <carlwgeorge> i keep coming back to just keeping the v in the package name
16:56:38 * decathorpe shrugs, that would work too
16:57:09 <decathorpe> either way, we've been bikeshedding on this for 50 minutes now
16:57:46 <geppetto> :)
16:57:48 <decathorpe> I'd put this into the filed ticket: either amend the package naming to not drop the "v" from the import path, or document the exception for using a hyphen as a separator for thus purpose
16:59:15 <geppetto> sounds good to me
17:00:37 <carlwgeorge> yup, wfm
17:01:22 <geppetto> Ok, on that note…
17:01:25 <geppetto> #endmeeting