4855 - (spec) Add rpm .spec files to source tarballs.

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, enhancement, P2)

Description

[ramiro]

fixed.

Comment 1

[timeless]

cls is pretty sure this bug regressed.

Comment 2

[timeless]

reassigning marking future and helpwanted per cls.

Comment 3

[cls]

Blizzard, are the spec files you're using for your rpms in the tree?

Comment 4

[Christopher Blizzard (:blizzard)]

No, they aren't.

Comment 5

[cls]

Blizzard's spec files, his bug.

Comment 6

[u27431]

Is TalkBack enabled in RPM builds?  It does not appear to be and I think it
would be good.  This seemed like the best bug to post this under since it'll go
to Blizzard. :)  Let me know if I should file a separate bug.

Comment 7

[timeless]

Assuming blizzard is outside of netscape, he probably can't make talkback 
builds.  There's always ramiro's hack.

Comment 8

[Christopher Blizzard (:blizzard)]

*** Bug 81972 has been marked as a duplicate of this bug. ***

Comment 9

[Braden]

Poke.

It would be really nice to get the spec file(s) into mozilla.org CVS. Hopefully
this would serve to stem some of the fragmentation we're beginning to see (which
will probably only continue to get worse under the current scenario).
Specifically, we have Ximian distributing RPMs that separate NSPR into its own
binary packages, while the Mozilla/Red Hat RPMs lump this in with the primary
mozilla package. How long before we see more divergence?

This kind of thing makes build configuration for clients of Mozilla harder than
it ought to be, and for no good reason at all. It seems like getting the spec
file(s) into mozilla.org CVS would be the logical first step toward encouraging
consensus regarding the details of installation.

Comment 10

[Chris Hiner]

Are either of these 2 files that I found with lxr the spec files in question:

/mozilla/source/build/package/rpm/mozilla.spec
/mozilla/source/xpinstall/packager/unix/mozilla.spec.in

Just trying to see if some of these old bugs are still valid.  Sorry for the spam.

Comment 11

[Christopher Blizzard (:blizzard)]

It's still valid and I'm going to be checking in the spec files I use RSN.

Comment 12

[Christopher Blizzard (:blizzard)]

My most recent spec files are in the tree already.

Comment 13

[Aleksey Nogin]

There still are some outdated files in the Mozilla CVS:
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/unix/genSpecFile.pl
http://lxr.mozilla.org/mozilla/source/xpinstall/packager/unix/mozilla.spec.in

BTW, answering [e-mail]'s question about talkback RPMs - see bug
86068

Comment 14

[timeless]

vrfy fixed
and the two obsolete files do not exist anymore :)

Comment 15

[Aleksey Nogin]

Well, the files got removed in January (with a comment saying they are "not
maintained here anymnore"). :-( IMO the spec files are needed in the mozilla's
CVS, not just in Red Hat's one - so that those who want to build their own RPMs
(hopefully this will include mozilla.org some day) can do so w/o having to go
some place else for the .spec file.

Comment 16

[Simon Paquet [:sipaq]]

*** Bug 328223 has been marked as a duplicate of this bug. ***

Comment 17

[Philip Prindeville]

(In reply to comment #15)
> Well, the files got removed in January (with a comment saying they are "not
> maintained here anymnore"). :-( IMO the spec files are needed in the mozilla's
> CVS, not just in Red Hat's one - so that those who want to build their own RPMs
> (hopefully this will include mozilla.org some day) can do so w/o having to go
> some place else for the .spec file.

Is there likely to be any movement on this issue?

Can someone at least publish a link to an external .spec file on the project's web pages?

Comment 18

[Benjamin Smedberg]

I'm convinced that we don't want to publish mozilla.org RPMs. If we do anything other than our current tarballs, it should be autopackages.

Comment 19

[Philip Prindeville]

(In reply to comment #18)
> I'm convinced that we don't want to publish mozilla.org RPMs. If we do anything
> other than our current tarballs, it should be autopackages.

I did mention putting a link to an unofficial external .spec file as a compromise.

In any case, I think this is unfortunate:  you'd get a larger base of users to try the software and provide feedback if it were easier to build and drop into place.

Comment 21

[Aleksey Nogin]

Can this be revisited perhaps? Perhaps separately for Firefox and Seamonkey (the dup bug 364949 was filed against firefox).

Note that this bug does not ask for the RPMs to be built or provided for download, only for a spec file to be included in the source tarballs.

Comment 22

[Nick Thomas [:nthomas] (UTC+12)]

Have you read http://steelgryphon.com/blog/?p=96 ? Seems to me there is now even less incentive to start into the nightmare of maintaining a spec file.

Comment 23

[Chris Cooper [:coop] (he/him)]

(In reply to comment #21)
> Note that this bug does not ask for the RPMs to be built or provided for
> download, only for a spec file to be included in the source tarballs.

(In reply to comment #21)
> Note that this bug does not ask for the RPMs to be built or provided for
> download, only for a spec file to be included in the source tarballs.

Yes, but including a spec file implies that we have invested enough effort into the process to make sure it works, and will continue to work as time goes on. Why not also provide .debs? It's a slippery slope. Packaging beyond the source/tarball we provide now for Linux is the domain of the Linux distributions, IMO. 

See also comment #18.

The firefox src rpms from Fedora/RHEL would be a good place to look for a spec file if you really need one.

Comment 24

[Philip Prindeville]

(In reply to comment #23)

> (In reply to comment #21)
> > Note that this bug does not ask for the RPMs to be built or provided for
> > download, only for a spec file to be included in the source tarballs.
> 
> Yes, but including a spec file implies that we have invested enough effort into
> the process to make sure it works, and will continue to work as time goes on.
> Why not also provide .debs? It's a slippery slope. Packaging beyond the
> source/tarball we provide now for Linux is the domain of the Linux
> distributions, IMO. 

Ok, let's take that argument in the opposite direction:  Why not take out the Makefiles and the configure.ac files, since they imply platform support and invested effort.  Why not push back and say that the configure.ac and Makefile.am's are also the responsibility of each of the distros?

> See also comment #18.
> 
> The firefox src rpms from Fedora/RHEL would be a good place to look for a spec
> file if you really need one.

Fine.  Then package it with the understanding that it's just a point-of-departure, a starting point... that it's delivered "as is".

Realistically, no one expects the code base to be perfect:  just that a reasonable level of diligence is exerted to maintain its quality and reliability.

Similarly, I don't really think anyone has a standard of expectations that is significantly higher for the platform packaging.

Comment 25

[Mike Shaver (:shaver emeritus)]

Advocates of having in-tree spec or autopackage or ... files would probably find their requests received more eagerly if they were to maintain an external package descriptor for some meaningful amount of time (few months?) and _then_ volunteer to maintain it in the tree itself.  If nobody's going to sign up (credibly) to maintain the packaging metadata, then nothing should go into the tree; we haven't seen anyone volunteer their time for that so far, so it's unlikely to progress farther on the basis of this current line of discussion.

Adding another thing to maintain to the standard of the current packaging is _not_ a trivial cost, and "as-is, point-of-departure" stuff should, IMO, be proven out outside the tree before they're included in our tarballs (and therefore generate support questions and doesn't-work-with-rpm3-on-AS400-etc bug reports, etc.).

Comment 26

[Ed Avis]

In the old days Mozilla used to package releases as binary RPMs.  If you do that, you need to maintain a spec file and it makes sense to put it in the source tarball.  Conversely, if you do include a spec file then you might as well use it and build RPM packages, not least because if it's not used regularly it will tend to rot.  So maybe you should maintain a spec file if and only if you release binaries in RPM format.  (Obviously, the person maintaining the spec file must be the same person using it to build packages.)