Hey, Petr On Mon, Sep 4, 2017 at 4:27 PM, Petr Stodulka <pstod...@redhat.com> wrote:
> 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. > > well, personally, I think the two solutions would be equivalent, while `make srpm` would be cleaner on API and easier to setup (the only diff would be that in the case of srpm the invocation would be always the same, otherwise there would be no diff). I might contact you for more information, but alright, if you feel the custom script is more convenient, then I am all for it. But first, I would like to make a proposal of each option (with screenshots and just complete feature request description) so that users can clearly see the options and pick what they like the best. We can work with Pavel on it. If you agree, I would post the two proposals here before actual implementation. > > > 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) <d...@redhat.com> > >>> 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@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > Petr Stodulka > Core Services (In-place upgrades and migrations) > IRC nicks: pstodulk, skytak > Red Hat > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
