On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup <praiskup@xxxxxxxxxx> wrote:
| Pavel
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.
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
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
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.
(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.
>Ok, even better -> allow specifying custom command, like:
>Git Repo:
> something.somewhere.git/
>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.
>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).
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
