On Tue, Jan 23, 2018 at 5:45 AM, <nicolas.mailhot@xxxxxxxxxxx> wrote: > > > ----- 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, > This was my main concern. There are plenty of people who don't like any of the known forges. And Go ecosystem incompetence for mandating URI-style deps and build paths doesn't really stop people from wanting to do that. > 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 > I don't consider them defective. They make me a bit squeamish because I don't see the spec preamble and such because they're autogenerated, but you've mentioned that it's possible to selectively use these things with Go and forge macros. SUSE does something similar with Python for their "singlespec" part, and it's fantastic[1][2]. But I'm slightly uncomfortable with the idea that there's no preamble *at all* in the spec using the Go macros and it's generated fully by macros. [1]: https://github.com/openSUSE/python-rpm-macros [2]: https://build.opensuse.org/package/view_file/openSUSE:Factory/python-iniparse/python-iniparse.spec?expand=1 > 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. > Technically, no one has to "accept" anything for the macros to be available. It's whether the macros would be broadly used. I could, in fact, tomorrow, make various extra useful macros that I use available in a package for people to pull in. It doesn't mean anyone has to use them. > 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. > As long as I can do Obsoletes/Provides for the old name for the devel, unit-test, etc. stuff so the old names work, it won't bother me too much. I want people to be able to do "snapd-devel" or whatnot and get the right thing. Though I'm not sure why package name enforcement is required for autodeps, since that's based on file lists passed to a dep generator... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
