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