Jeff Morriss
changed
bug 8190
| What |
Removed |
Added |
| CC |
|
jeff.morriss.ws@gmail.com
|
Comment # 15
on bug 8190
from Jeff Morriss
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > (In reply to comment #9)
> >
> > >
> > > BTW it would be nice to collect a few reasons why keeping the /debian dir
> > > seems to be the better idea. Just for the record. :-)
> >
> > For one: http://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBinary.html
> > Now it's just a one-liner: make debian-package to build your own packages.
> > This (and the RPM chapter) will have to be expanded on how to do / set this
> > up with other resources before we start ripping out packaging files.
>
> If you're an end-user you should be getting your packages from upstream
> (debian, fedora, etc.). If you're a maintainer you're used to building your
> own packages. I'm not immediately seeing a use case for non-maintainers that
> want to build their own custom packages from trunk?
Redhat is (apparently) even worse than Debian for Wireshark versions. Redhat
EL 5 (still in wide use) has *1.0.15*. Redhat EL 6 (not that old) comes with
*1.2.15*. Fedora 18 has finally picked up a 1.8 release (1.8.3).
I roll my own RPMs (at least for the EL's) because I have to: 1.0 and 1.2 are
simply too old and I don't want to hear people complaining about bugs fixed 5
years ago... And of course sometimes people actually need/want the newer
functionality. (Okay, I also thrown my proprietary dissectors there...)
Admittedly to build my own RPMs I started with the Redhat .spec files. As Jaap
suggested a while ago, I'm trying to find the time to update Wireshark's .spec
file to make this easier (and/or work better) for others. I was hoping once
I've done that to convince Redhat to pick up our version.
(I've answered a number of questions in the past few months about people
building RPMs for Redhat/CentOS 5 so it's not just me who wants modern
Wireshark on Redhat releases.)
Also of interest given the problem which spawned this bug: the only reason I
apply any patches when building my RPMs is to bring back features I want or to
apply my proprietary dissectors. AFAICS users have been able to use our
(not-modified-in-a-long-time) .spec file to build RPMs so while there's room
for improvement, keeping our own packaging file shouldn't be a maintenance
problem.
In reply to comment 5: back when I cared about Solaris I'd roll my own SVR4
packages too (for basically the same reasons as above). It was convenient to
not have to go to a 3rd party to figure out how to build those packages. And
again I don't think we've had to do much of any maintenance of that packaging
stuff so I don't see the harm in keeping it.
You are receiving this mail because:
- You are watching all bug changes.
