5:47 p.m.
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,
--
José Abílio
6:44 p.m.
On 12/15/06, José Matos <jamatos(a)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
7:43 p.m.
>>>> "TK" == Toshio Kuratomi
<a.badger(a)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<
7:09 a.m.
On Fri, Dec 15, 2006 at 07:43:04PM -0600, Jason L Tibbitts III wrote:
>>>>> "TK" == Toshio Kuratomi
<a.badger(a)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).
--
Axel.Thimm at ATrpms.net
7:16 a.m.
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
--
José Abílio
7:22 a.m.
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.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:50 a.m.
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"
--
Axel.Thimm at ATrpms.net
11:47 a.m.
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(a)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
12:18 p.m.
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(a)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
12:23 p.m.
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(a)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.
--
Axel.Thimm at ATrpms.net
12:49 p.m.
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(a)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.
--
Axel.Thimm at ATrpms.net
2:33 p.m.
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
3:40 p.m.
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
--
Axel.Thimm at ATrpms.net
4:01 p.m.
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
4:06 p.m.
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. :)
--
Axel.Thimm at ATrpms.net
6338
days inactive
6341
days old
packaging@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
Axel Thimm -
David Lutterkort -
Jason L Tibbitts III -
José Abílio Matos -
Matthew Miller -
Toshio Kuratomi