Re: CI projects in Copr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux