Hello Pavel,
On Thu, Aug 31, 2017 at 4:37 PM, Pavel Raiskup <prais...@redhat.com> wrote:
> On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote:
> > a) you need an additional db field. you need to have more inputs in SCM
> tabs
> > when one has a meaning only if 'custom' is selected in the srpm_generator
> > select (which means you should hide/unhide that by js in frontend to
> have nice
> > user experience), then on API, you need to have one selector (const
> argument)
> > for srpm_generator and then another field (name of the script) that has
> > meaning only if 'custom' has been selected (that will occur on more
> places in
> > the code).
>
> False. With 'make srpm' you still want to specify where the Makefile is.
> I hope you don't expect that the only-for-copr Makefiles will be added to
> the root of all the project in the wild...
>
> Anyway, I did not expected that you will complain about *one argument* in
> API or anywhere else, that's nitpick. How expensive is that? :) I can
> help you with this additional work, sure.
>
> > And having the selector in the first place is good because you can
> supply a
> > default value and you can implicitly point users to the well-established
> tools
> > where people can get more info about them and finally pick the tool most
> > suitable for them.
>
> Off-topic, selector picks among tito/mock-scm/py2rpm/... or
> arbitrary_script. Each method has an arguments.
>
> > Additionally `make srpm` carries the message so user knows what's
> expected.
>
> Why do you care how the end-user names the script? :)
>
> > There also needs to be some kind of uniformity because we need to put the
> > output srpm into the predefined place (git repo directory) and also such
> > scripts would usually tend to have similar names (gen_srpm.py,
> make_srpm.pl),
> > so automatically it is good to have a predefined choice, I mean...why
> not.
>
> How the "name of the generating tool" reflects where the result SRPM is
> put, and how "copr is going to import that"?
>
> > You can call your any_script.xyz from the Makefile.
>
> No, I __have to__, and that's the difference :) What's the benefit on
> enforcing it?
>
> > Everyone is familar with Makefiles and likes them (for simple things at
> > least).
>
> (rofl) I wish this was truth.
>
> > It's a nice tradition. And the approach is the same thing as defining a
> > callback method that is being called from a certain lib that goes back
> to your
> > code.
> >
> > b) I like Makefiles for simple things, I think it's a neat choice. Also I
> > hope that the default choice ('rpkg') will serve pretty well.
>
> I like Makefiles too, but that's not about my/your preferences.
>
> Yes, let's have rpkg/tito/mock-scm/xxx2rpm/.. methods to obtain sources,
> but
> let's have also a fall-back option which matches everybody else. After
> some time, we'll see how the fall-back is useful (and whether anybody
> still uses other declarative and not-flexible methods...).
>
> > c) Note that you can cover your use-case (of any-name script) by simply
> > calling that script by name from the Makefile if you want. So there is
> nothing
> > to be refactored.
>
> Will ninja people install some Makefile only because of CI in Copr? So
> you either will be adding ninja support (mistake), or you replace the
> "make srpm" build option with general one (api change that annoys users).
> That's the refactoring I'm talking about.
>
> Thanks,
> Pavel
>
Please, let's have an off-line talk. I think I can better clarify why I
think `make srpm`
is the best. It's mostly about where we are now and where we need to get.
Or if there is a concrete use-case that you know that will break, please
tell, so that
we can find a solution immediately.
But I think an off-line talk might be the best. Depends on you.
>
> > >Ok, even better -> allow specifying custom command, like:
> >
> > >Git Repo:
> > > something.somewhere.git/project/foo
> > >Command to get sources:
> > cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh
> --some-arg
> > >Packages needed to obtain sources:
> > help2man, gettext-devel, wget, git-lfs
> > >SRPM pattern:
> > packaging/rpm/fedora/xyz*.src.rpm
> >
> > >The pattern is important; plus we should declare that only the first
> > matched
> > >srpm is going to be built.
> >
> > This is already _very_ complicated at least for new users that we would
> > also like
> > to attract (in addition to satisfying power users).
> >
> > So these are my reasons. I am willing to discuss this but at the same
> time
> > I don't
> > want to spend too much time on this because it really is an
> implementation
> > detail.
> >
> > | Pavel
> >
> > On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup <prais...@redhat.com>
> wrote:
> >
> > > On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > > > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup <prais...@redhat.com>
> > > wrote:
> > > > > I'm curious why you insist on 'make srpm'; that sounds like you
> try
> > > to push
> > > > > the copr users somewhere, to "standardize something".
> > > >
> > > > It's easier on implementation. That's the main reason. I generally
> > > believe
> > > > that what's easier on implementation is better.
> > >
> > > This is not first time we talk about this...
> > >
> > > (a) can you elaborate what's "easier" to implement on the 'make srpm'
> way?
> > >
> > > (b) shouldn't you make a life easier to your users? Even when I really
> > > like
> > > make, what's easier on "enforcing" Makefile existence to be able to
> > > enable CI in copr?
> > >
> > > (c) Wrong general belief, please, forget about that. Doing it wrong
> (== an
> > > "easier" way) in the beginning is much more expensive in the end
> (try
> > > to
> > > grep for "refactor" word...). The proposal is to have "one method"
> > > which suits everybody; and never touch it again. But yeah,
> no-thanks
> > > for
> > > not listening. Again.
> > >
> > > Pavel
> > >
> > >
> >
>
>
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
