I apologize for late response as I was on holiday. Not sure if you already talked together about that but I agree with Pavel. `make srpm` solves only _one_ type of troubles. I guess that usually I will get response from upstream like that: -- we will not add Makefile just because of COPR that is not important for us in any way -- we will not modify Makefile just because of... etc. It would work for us where we are upstream, but it is just another mess next to _setup.py_ for example. Really, the possibility of own script inside copr is much more convenient, it is more generic solution and covers many more troubles. Personally from my point of view, I would rather invest (e.g.) one more week to generic solution than save that time for partial solution. But I don't see into the COPR and I will not work on it so I am not saying that it has to be done in that way. On 4.9.2017 09:47, Pavel Raiskup wrote: > On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: >> On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) <duck@xxxxxxxxxx> >>> On 09/01/2017 01:28 AM, Michal Novotny wrote: >>>> But I think an off-line talk might be the best. Depends on you. >>> >>> I can understand you don't want this thread to end-up in flames, and yes >>> sometimes it helps to have a live direct talk, but this also means the rest >>> of this list is kept out. I think it would be best to improve on >>> collaborative talks together. Also being asked for rational may seem boring >>> but is really necessary to understand each-other and is in no way a >>> provocative behavior, even if Pavel seems to like teasing you :-). >> >> sure it would be good but what I would really like to see is a particular >> concrete, real-world use-case that will not work. Then it would be quite easy >> to find a solution. > > Sure, real world example [1]. There's no Makefile in the root directory (and I > don't even plan to propose adding it as that's java project, so 'make srpm' is > sort of no-go). > > We agreed with upstream on the (super-ugly btw.) directory structure under > packaging/rpm; I hope this is one day to be replaced by trivial: > > packaging/rpm/generate-srpm.sh > packaging/rpm/spec.template > >> Well, we can continue discussion e.g. also in PRs if people are interested >> in this. > > Accepted, though I thought that we could s/make srpm/any command/ right now to > avoid spending additional bucks later with the PRs. Likely, once the new build > method is added we'll maintain it forever so the bad decision is not completely > free of charge. > > [1] https://github.com/pgjdbc/pgjdbc > > Pavel > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- Petr Stodulka Core Services (In-place upgrades and migrations) IRC nicks: pstodulk, skytak Red Hat
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
