Closed
Bug 4855
(spec)
Opened 26 years ago
Closed 18 years ago
Add rpm .spec files to source tarballs.
Categories
(SeaMonkey :: Build Config, enhancement, P2)
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: ramiro, Unassigned)
References
Details
(Keywords: helpwanted)
Reporter | ||
Updated•26 years ago
|
Priority: P3 → P2
Target Milestone: M4
Reporter | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
fixed.
cls is pretty sure this bug regressed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: M4 → ---
reassigning marking future and helpwanted per cls.
Blizzard, are the spec files you're using for your rpms in the tree?
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
No, they aren't.
Blizzard's spec files, his bug.
Assignee: cls → blizzard
Status: ASSIGNED → NEW
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.
Assuming blizzard is outside of netscape, he probably can't make talkback
builds. There's always ramiro's hack.
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•23 years ago
|
||
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•23 years ago
|
||
It's still valid and I'm going to be checking in the spec files I use RSN.
Comment 12•23 years ago
|
||
My most recent spec files are in the tree already.
Status: NEW → RESOLVED
Closed: 26 years ago → 23 years ago
Resolution: --- → FIXED
Comment 13•23 years ago
|
||
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 fdjsouthey@uwaterloo.ca's question about talkback RPMs - see bug
86068
Comment 14•22 years ago
|
||
vrfy fixed
and the two obsolete files do not exist anymore :)
Status: RESOLVED → VERIFIED
QA Contact: Chris.Yeh → granrose
Comment 15•21 years ago
|
||
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.
Updated•20 years ago
|
QA Contact: granrosebugs → cmp
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 16•19 years ago
|
||
*** Bug 328223 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
(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•19 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 19 years ago
Resolution: --- → WONTFIX
Comment 19•19 years ago
|
||
(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•18 years ago
|
||
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.
Alias: spec
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: need linux rpm packaging spec files in the build → Add rpm .spec files to source tarballs.
Updated•18 years ago
|
Assignee: blizzard → nobody
Status: REOPENED → NEW
QA Contact: chase → build-config
Comment 22•18 years ago
|
||
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•18 years ago
|
||
(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.
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WONTFIX
Comment 24•18 years ago
|
||
(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.
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•18 years ago
|
||
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.)
You need to log in
before you can comment on or make changes to this bug.
Description
•