rpm folder

[Jiri Kastner]

hi,
i plan remove rpm folder in all packages and also makefile and move all setup/install tasks to setup.py.
therefore all patches which are changing rpm folder and specfile are not going to be accepted :)

best regards
jiri kastner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/tuna-devel/attachments/20140130/b954e5ed/attachment.sig>

[David Sommerseth]

hi, i plan remove rpm folder in all packages and also makefile and
move all setup/install tasks to setup.py. therefore all patches
which are changing rpm folder and specfile are not going to be
accepted :)

Just thinking aloud ... Is this so clever? What is the problem with
having the RPM directory and spec file there?

I would however, consider spec files shipped in a project to be more
"distro neutral". And then rpmbuild can be used on other
non-RHEL/Fedora platforms easily, such as SuSE and Mandrake/Mandriva,
to mention a few. I think of rpmbuild -t{a,b,s} <tarball> in particular.

For official inclusion in each of the distros, a different spec file
will most likely needed, but this spec file can then serve as a nice
template to start with.


Just my 2 cents.


- --
kind regards,

David Sommerseth

[Jiri Kastner]

now everything is done via rpm specfile, setup.py (and/or makefile) does nothing.
that's what i want to achieve: make specfile stupid simple and setup.py more complex, to have tuna more friendly for rpm-less distros.
and that specfile is useless in age of tito, koji, copr and mock (what's more, stored in bad place).
if so, i vote for tuna.spec.in without changelog part, modified only when some new file will be added.

best regards
jiri kastner

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi, i plan remove rpm folder in all packages and also makefile and
move all setup/install tasks to setup.py. therefore all patches
which are changing rpm folder and specfile are not going to be
accepted :)

Just thinking aloud ... Is this so clever? What is the problem with
having the RPM directory and spec file there?
I would however, consider spec files shipped in a project to be more
"distro neutral". And then rpmbuild can be used on other
non-RHEL/Fedora platforms easily, such as SuSE and Mandrake/Mandriva,
to mention a few. I think of rpmbuild -t{a,b,s} <tarball> in particular.
For official inclusion in each of the distros, a different spec file
will most likely needed, but this spec file can then serve as a nice
template to start with.
Just my 2 cents.
- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLqXIEACgkQIIWEatLf4HcN3ACeIrq9B67fsaNuiB6rPNRyJA0C
+iUAni/RH+KyOP1V/IQ9chqpRxDmGvkL
=wQ7s
-----END PGP SIGNATURE-----
_______________________________________________
tuna-devel mailing list
tuna-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/tuna-devel/attachments/20140130/e22a9e27/attachment.sig>

[John Kacur]

----- Original Message -----

Post by Jiri Kastner
now everything is done via rpm specfile, setup.py (and/or makefile) does nothing.
that's what i want to achieve: make specfile stupid simple and setup.py more
complex, to have tuna more friendly for rpm-less distros.
and that specfile is useless in age of tito, koji, copr and mock (what's
more, stored in bad place).
if so, i vote for tuna.spec.in without changelog part, modified only when
some new file will be added.
best regards
jiri kastner

I think it's probably okay, but maybe you want to deprecate it slowly like
they would do in the kernel. Say, maybe that you'll keep it for one or two more
releases, and then it will be gone unless there is a good reason not to remove it

Thanks

John

Post by Jiri Kastner

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi, i plan remove rpm folder in all packages and also makefile and
move all setup/install tasks to setup.py. therefore all patches
which are changing rpm folder and specfile are not going to be
accepted :)

Just thinking aloud ... Is this so clever? What is the problem with
having the RPM directory and spec file there?
I would however, consider spec files shipped in a project to be more
"distro neutral". And then rpmbuild can be used on other
non-RHEL/Fedora platforms easily, such as SuSE and Mandrake/Mandriva,
to mention a few. I think of rpmbuild -t{a,b,s} <tarball> in particular.
For official inclusion in each of the distros, a different spec file
will most likely needed, but this spec file can then serve as a nice
template to start with.
Just my 2 cents.
- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLqXIEACgkQIIWEatLf4HcN3ACeIrq9B67fsaNuiB6rPNRyJA0C
+iUAni/RH+KyOP1V/IQ9chqpRxDmGvkL
=wQ7s
-----END PGP SIGNATURE-----
_______________________________________________
tuna-devel mailing list
tuna-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel

_______________________________________________
tuna-devel mailing list
tuna-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel

[Guy Streeter]

hi, i plan remove rpm folder in all packages and also makefile and move
all setup/install tasks to setup.py. therefore all patches which are
changing rpm folder and specfile are not going to be accepted :)

How can you use setup.py to produce an rpm file for rpm distros like Fedora
and RHEL?

- --Guy

best regards jiri kastner
_______________________________________________ tuna-devel mailing list
tuna-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/tuna-devel

[Guy Streeter]

hi, i plan remove rpm folder in all packages and also makefile and move
all setup/install tasks to setup.py. therefore all patches which are
changing rpm folder and specfile are not going to be accepted :)
best regards jiri kastner

If I understand correctly, you'd like to make sure people can install from
source using setup.py, even on a non-rpm distro. I think that's fine, if you
understand how setup.py works. I don't, and I could only do what I could
find examples for.

However, I don't see a reason to remove the rpm files. They are still useful
for creating an rpm. Those of us on rpm distros would generally prefer to
install packages with an rpm, even when we're working with the source code.

- --Guy