Hey, Petr
On Mon, Sep 4, 2017 at 4:27 PM, Petr Stodulka <pstodulk(a)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) <duck(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org