----- 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