Ethereal-dev: Re: [Ethereal-dev] The Ethereal RPMs mess
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Devin Heitmueller <dheitmueller@xxxxxxxxxxx>
Date: Mon, 22 Dec 2003 23:10:46 -0000
The way you described it is pretty much the standard convention. Typically, there is a single spec file, which can output several binary packages. As Guy pointed out, you want to be sure to separate out the stuff required for tethereal versus the stuff for the GTK version. Frankly, I'm not sure how the current spec file is organized. Is the tethereal package inside of ethereal-common? Here is what I would recommend in a perfect world: There should be a ethereal-ucd-snmp RPM, which contains libethereal.so. There should also be an ethereal-net-snmp and ethereal-no-snmp RPM, which also provide libethereal. All three would have a "provide" of "libethereal". Also, each of the three would have an RPM requires for their respective version of libsnmp. Then there would be an ethereal-gtk, which would have an RPM requires of "libethereal", and this would have the main ethereal GTK binary. There would also be a ethereal-text, which contains tethereal and has an RPM requires for libethereal. Note that all three of the ethereal-*snmp subpackages provide "libethereal". This is so that the User Interface RPMs require one of the ethereal-*snmp RPMs to be installed. It also means that you cannot have multiple versions installed at once, since they all provide "libethereal". This scheme would provide a clear separation between the core decoding library which is shared, and the different front-ends (currently GTK and tethereal). Of course, I don't think it is currently separated out into a library at this time. Devin On Mon, 2003-12-22 at 19:15, Richard Sharpe wrote: > On 22 Dec 2003, Devin Heitmueller wrote: > > > You need to do RPM subpackages. This would allow you to generate three > > different binary RPMs from one source RPM. > > > > The online version of Maximum RPM describes it at the following link: > > > > http://www.rpm.org/max-rpm/ch-rpm-subpack.html > > > > If you have any trouble, send me an email and I'll see what I can do. > > Thank you very much for that hint. It looks like what I want. > > Did you have any comments on my claimed simplification of the packages? > > > Devin > > > > On Mon, 2003-12-22 at 18:56, Richard Sharpe wrote: > > > Hi folks, > > > > > > I am looking at better ways to package the RPMs for Ethereal. > > > > > > I want to build three sets of packages: > > > > > > 1. built with ucd-snmp packages > > > > > > 2. built with net-snmp packages > > > > > > 3. Built without snmp at all. > > > > > > Currently, I use three spec files, but that creates problems with the > > > source RPMs and a mish-mash of RPMs that require people to know what > > > packages to install. > > > > > > I think that it would be better if: > > > > > > 1. I could come up with one spec file > > > > > > 2. I built three packages, ethereal-no-snmp, ethereal-net-snmp, > > > ethereal-ucd-snmp, which installed everything. This will simplify the > > > installation decisions for people. > > > > > > Does anyone have any opinions on this? > > > > > > Also, can anyone point me at resources that can teach me how to build > > > three packages from one SPEC file? > > > > > > Regards > > > ----- > > > Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, > > > sharpe[at]ethereal.com, http://www.richardsharpe.com > > > > > > _______________________________________________ > > > Ethereal-dev mailing list > > > Ethereal-dev@xxxxxxxxxxxx > > > http://www.ethereal.com/mailman/listinfo/ethereal-dev > > -- Devin Heitmueller Senior Software Engineer Netilla Networks Inc.
- References:
- Re: [Ethereal-dev] The Ethereal RPMs mess
- From: Richard Sharpe
- Re: [Ethereal-dev] The Ethereal RPMs mess
- Prev by Date: Re: [Ethereal-dev] The Ethereal RPMs mess
- Next by Date: [Ethereal-dev] SMPP updates
- Previous by thread: Re: [Ethereal-dev] The Ethereal RPMs mess
- Next by thread: Re: [Ethereal-dev] The Ethereal RPMs mess
- Index(es):