I am reviewing [Bug 219751] Review Request: python-TurboMail
In the spec file Luke has packaged the egg files for that package. What is Fedora policy regarding this issue. Should we package the egg files or should we leave them?
I remember that we have discussed this sometime ago but I don't remember the outcome.
Regards,
On 12/15/06, José Matos jamatos@fc.up.pt wrote:
I am reviewing [Bug 219751] Review Request: python-TurboMail
In the spec file Luke has packaged the egg files for that package. What is Fedora policy regarding this issue. Should we package the egg files or should we leave them?
I think we should package them. I think tibbs had the opposite viewpoint but I don't remember if we got to a point where he decided it didn't matter or we came to an agreement or just let it drop.
-Toshio
"TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
- J<
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
"TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
On Saturday 16 December 2006 1:09 pm, Axel Thimm wrote:
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
On one hand I agree with Axel, on the other this allows installations per user, no?
What is our policy regarding other programming language ( with their repositories cpan, cran, ctan)...
This should probably be a general policy, no?
-- Axel.Thimm at ATrpms.net
On Sat, Dec 16, 2006 at 01:16:08PM +0000, José Matos wrote:
What is our policy regarding other programming language ( with their repositories cpan, cran, ctan)...
Don't ever use CPAN directly. It can really muck up your system.
On Sat, Dec 16, 2006 at 01:16:08PM +0000, José Matos wrote:
On Saturday 16 December 2006 1:09 pm, Axel Thimm wrote:
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
On one hand I agree with Axel, on the other this allows installations per user, no?
What is our policy regarding other programming language ( with their repositories cpan, cran, ctan)...
A user may download tarballs, cpan/ctan, alienated debs and install them under $HOME or /usr/local, we don't mandate anything about that places. But we wouldn't start shipping rpm-foreign bits to endorse people doing so - especially not, if they would override the rpm itself that is shipping the egg for example.
E.g. the user has an issue with the package (maybe a real bug, maybe just not rtfm), sees the egg, erroneously thinks that he needs to complete the rpm installation by using it and does so. Later package updates are not seen anymore by the user, since he's using a local copy of the previous package.
This should probably be a general policy, no?
Well, even if it is not written down somewhere explicitely it is rather assumed. It is also a difficult wording, of course the user is free to use debs, ctan, eggs and so on, and we won't explicitely forbid this, but we shouldn't push users to do so either.
Perhaps: "Packaging tarballs or other non-rpm packaging formats within the package is strongly discoursaged as it may misguide users to override the package by using them"
On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote:
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
> "TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
David
On Mon, 2006-12-18 at 17:47 +0000, David Lutterkort wrote:
On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote:
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
>> "TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
+1
Some end users are going to install via eggs/gems/cpan anyways. It's better if we allow them to use as many FE packages as possible when they do this, rather than forcing them to install duplicates of packages they already have installed via rpm.
-Toshio
On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote:
On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote:
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
>> "TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
Don't you have the same issue if you install the egg with -Z? If not, then the (egg-)package dependencies are obvioulsy spooled somewhere on disk for easy_install and friends to find.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
If you like so, having "egg-provides" is fine, of course. Just like we have foo.pc, but don't keep the full tarball around.
On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote:
On Sat, 2006-12-16 at 14:09 +0100, Axel Thimm wrote:
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
>>> "TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> I think tibbs had the opposite viewpoint but I don't remember if TK> we got to a point where he decided it didn't matter or we came to TK> an agreement or just let it drop.
I guess the point is that I can't figure out what additional value it adds, and in general it's bad to package up something that's completely needless.
egg is a packaging method that is orthogonal to what we use. Leaving the eggs around may get users to start using egg-installation and get files on the system unregistered by rpm.
Or not? If the above is correct eggs should even be banned just as other non-native package formats are banned (debs or tarballs for example).
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
Don't you have the same issue if you install the egg with -Z? If not, then the (egg-)package dependencies are obvioulsy spooled somewhere on disk for easy_install and friends to find.
Looks like all has been considered in advance by the egg folks:
--single-version-externally-managed This boolean option tells the install command to perform an "old style" installation, with the addition of an .egg-info directory so that the installed project will still have its metadata available and operate normally. If you use this option, you must also specify the --root or --record options (or both), because otherwise you will have no way to identify and remove the installed files.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
If you like so, having "egg-provides" is fine, of course. Just like we have foo.pc, but don't keep the full tarball around.
The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information.
On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote:
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
Don't you have the same issue if you install the egg with -Z? If not, then the (egg-)package dependencies are obvioulsy spooled somewhere on disk for easy_install and friends to find.
Looks like all has been considered in advance by the egg folks:
--single-version-externally-managed This boolean option tells the install command to perform an "old style" installation, with the addition of an .egg-info directory so that the installed project will still have its metadata available and operate normally. If you use this option, you must also specify the --root or --record options (or both), because otherwise you will have no way to identify and remove the installed files.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
If you like so, having "egg-provides" is fine, of course. Just like we have foo.pc, but don't keep the full tarball around.
The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information.
Heh. This is what we've been doing :-)
From lmacken's TurboMail spec, for instance: %files %defattr(-,root,root,-) %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info
-Toshio
On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote:
On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 07:23:29PM +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 05:47:48PM +0000, David Lutterkort wrote:
The crucial issue are the dependencies that right now have to stay within each packaging format; if rpm's can't contain any egg (or gem or whatnot) info, users will end up installing the same package twice, just to fulfill dependencies completely within each packaging system.
Don't you have the same issue if you install the egg with -Z? If not, then the (egg-)package dependencies are obvioulsy spooled somewhere on disk for easy_install and friends to find.
Looks like all has been considered in advance by the egg folks:
--single-version-externally-managed This boolean option tells the install command to perform an "old style" installation, with the addition of an .egg-info directory so that the installed project will still have its metadata available and operate normally. If you use this option, you must also specify the --root or --record options (or both), because otherwise you will have no way to identify and remove the installed files.
It would be much more userfriendly if we laid the groundwork for other packaging systems to depend on rpm-installed bits; that mostly means to _allow_ inclusion of non-rpm packaging metadata in rpms.
If you like so, having "egg-provides" is fine, of course. Just like we have foo.pc, but don't keep the full tarball around.
The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information.
Heh. This is what we've been doing :-)
Then why are we trying to change that?
From lmacken's TurboMail spec, for instance: %files %defattr(-,root,root,-) %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info
On Mon, 2006-12-18 at 22:40 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote:
On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote:
The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information.
Heh. This is what we've been doing :-)
Then why are we trying to change that?
From lmacken's TurboMail spec, for instance: %files %defattr(-,root,root,-) %{python_sitelib}/TurboMail-%{version}-py%{pyver}.egg-info
I think it was confusion from inexact wording in the original post. I knew what lmacken had been doing in Turbo* packages so I replied with the idea that "egg files" meant these files inside the .egg-info directory. Meanwhile you took it to mean the zipped up PACKAGE.egg files.
In any case, it looks like TurboMail was approved and the cvs version shows that it's including the .egg_info directory not the .egg files.
I think we're in agreement that this is the correct way to go?
-Toshio
On Mon, Dec 18, 2006 at 02:01:27PM -0800, Toshio Kuratomi wrote:
On Mon, 2006-12-18 at 22:40 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 12:33:19PM -0800, Toshio Kuratomi wrote:
On Mon, 2006-12-18 at 19:49 +0100, Axel Thimm wrote:
The equivalent to *.pc files seem to be the .egg-info subdirs. So we don't need to ship the egg file in addition within the rpm file, but still feed the egg packaging system with information.
I think it was confusion from inexact wording in the original post. I knew what lmacken had been doing in Turbo* packages so I replied with the idea that "egg files" meant these files inside the .egg-info directory. Meanwhile you took it to mean the zipped up PACKAGE.egg files.
In any case, it looks like TurboMail was approved and the cvs version shows that it's including the .egg_info directory not the .egg files.
I think we're in agreement that this is the correct way to go?
Fully. :)
packaging@lists.fedoraproject.org
-
Axel Thimm -
David Lutterkort -
Jason L Tibbitts III -
José Abílio Matos -
Matthew Miller -
Toshio Kuratomi