On Jan 23, 2018 12:41, <nicolas.mailhot@xxxxxxxxxxx> wrote:
>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
----- Mail original -----
De: "Neal Gompa"
>
>>> 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>> By not using the macros for packages not fitting the model?
>>> people who release Go code as tarballs (it's rare, but it happens).
>>> How do you deal with that?
>>
>>
> 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.
So, if I understand correctly, both the forge stuff and the new macros for go packaging are completely opt-in?
If that's correct, this looks like the best solution to me - as old packages can then be converted one at a time (which I am looking forward to doing for my go packages, btw.).
Fabio
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
