Hello Pavel,
On Thu, Aug 31, 2017 at 4:37 PM, Pavel Raiskup <praiskup@xxxxxxxxxx> 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.
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 <praiskup@xxxxxxxxxx> 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 <praiskup@xxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
