----- Mail original ----- De: "Neal Gompa"
>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune > >>> I really do like this. There are only two issues I have with it: >>> >>> 1. This seems to mandate that all packages must be named by their >>> import path. My golang package (snapd) is not, intentionally so. I >>> don't want to change this. >>> >>> 2. Mandating a forge is going to be tricky for self-hosted stuff, or >>> people who release Go code as tarballs (it's rare, but it happens). >>> How do you deal with that? >> >> By not using the macros for packages not fitting the model? >> > The issue is that the new Go macros are tightly wound into the forge > macros. I just want to be sure that we can leverage things like the > dependency generators without all the other stuff. Hi Neal, I should probably not let this pass without clarifying: 1. if your concern is that the *forge* macros will block packaging of projects not hosted on known forges, they won't: — they include code to disable transparently and without exploding the associated bits if the hosting site is unknown — the packager can pre-define the variables that would have been computed if the site was known and all the rest of the automation will just work — baring that the packager can ignore the site-related computations and use whatever he wants instead in Source: and *setup, which are the only parts that depend on hosting structure knowledge, 2. if your concern is that the *forge* macros are defective somewhere I'd be curious where as you'd be the first to report an actual technical problem. I've used them intensively in rawhide and el7 with many different rpm tools and they are rock solid for me 3. if your concern is that they won't ever be merged due to some people non-constructive obstruction, well I share it to some point but I won't spend more time arguing unicorns and what-if-maybe I-don't-like-commits-let's-make-them-awful-to-use. The people blocking there are free to take up the maintenance of my ~400 specs and redo them as they want, we'll see how they love to waste tens of minutes per spec to position setup args manually when they have to do it for hundreds of them, every time there is a package update or a forge relayout. The main difficulty with the proposal is not the *forge part, it's that automated autodeps are well, automated. As every automation they are strict and unyielding and do not take approximations well. They will fail spectacularly in the following cases: 1. the packager does not package all the deps of its code → the resulting package is uninstallable because autodeps add requires on missing bits 2. the packager packages code with garbage imports (very common in example or test code) → the resulting package is uninstallable because autodeps add require 3. the packager does not own properly the directories where its Go code is installed → given that Go deps depend on directories, Go autodeps also depend on proper directory ownership. Positioning autodeps on Go files themselves would make package build times increase many many times as rpm would try to compute the same autodeps for every single .go file in a directory. (and Go autodeps are already sloooow as snails because invoking the go command is slow) All those things are mitigated by the use of %goinstall that filters usual example/test/vendor dirs so they don't trigger autodeps, and tries very hard to own all relevant directories. For those reasons I don't propose to activate autodeps in old-style golang packages. They need conversion (and review by a human to check no problem code is deployed) first. Regards, -- Nicolas Mailhot _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@lists.fedoraproject.org
