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.
>
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). 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. Additionally `make srpm`
carries the message
so user knows what's expected. 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.
You can call
your any_script.xyz from the Makefile. Everyone is familar with Makefiles
and likes them
(for simple things at least). 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.
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.
>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
