Where to report a bug?

Mon Apr 10 17:00:08 UTC 2023

At Mon, 10 Apr 2023 11:09:56 -0500 "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:

> 
> On 4/10/23 7:38 AM, Robert Heller wrote:
> > At Mon, 10 Apr 2023 00:59:12 -0500 "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
> > 
> >>
> >> On 4/9/23 9:26 PM, Robert Heller wrote:
> >>> At Sun, 9 Apr 2023 16:26:21 -0500 "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
> >>>
> >>>>
> >>>> On 4/9/23 2:37 PM, Robert Heller wrote:
> >>>>> I need to report a bug (which I thought I reported years ago).
> >>>>>
> >>>>> It is just a packaging error:
> >>>>>
> >>>>> For some reason, installing bison++ causes bison to be removed (and vice
> >>>>> versa). This is not really necessary -- bison++ does not actually conflict
> >>>>> eith bison. The two packages are completely independent. Yes, from some points
> >>>>> of view they can be said to be replacements of each other, but they are
> >>>>> different and it does make sense to have both installed at the same time.
> >>>>>
> >>>>
> >>>> Here's your bug report
> >>>> https://bugs.launchpad.net/ubuntu/+source/bison++/+bug/1607408
> >>>>
> >>>> The reason there's a conflict is due to both bison and bison++ supplying
> >>>> /usr/bin/bison, which is a filename collision. AIUI, bison++ is based on
> >>>> a older version of bison so it makes sense that it has a /usr/bin/bison
> >>>> that's different from the one supplied by the bison package.
> >>>
> >>> bison++ supplies /usr/bin/bison++, NOT /usr/bin/bison.  There aren't any
> >>> actual file conflicts.
> >>
> >> Yes, there is. You can confirm this for yourself.
> >> $ apt download bison
> >> $ apt download bison++
> >> These commands  will download the deb packages from the repos to the
> >> current working directory.
> >>
> >> $ dpkg-deb -c bison__2%3a3.8.2+dfsg-1build1_amd64.deb |grep bin
> >> drwxr-xr-x root/root         0 2022-03-23 04:43 ./usr/bin/
> >> -rwxr-xr-x root/root    504624 2022-03-23 04:43 ./usr/bin/bison
> >> -rwxr-xr-x root/root      4214 2022-03-23 04:43 ./usr/bin/bison.yacc
> >>
> >> $ dpkg-deb -c bison++_1.21.11-5_amd64.deb |grep bin
> >> drwxr-xr-x root/root         0 2021-10-24 01:32 ./usr/bin/
> >> -rwxr-xr-x root/root     89176 2021-10-24 01:32 ./usr/bin/bison
> >> -rwxr-xr-x root/root     89176 2021-10-24 01:32 ./usr/bin/bison++
> >> -rwxr-xr-x root/root        30 2021-10-24 01:32 ./usr/bin/bison++.yacc
> >>
> >> The bison executable in the bison package is 504624 bytes while the one
> >> in the bison++ package is 89176 bytes. They're different executables
> >> with the same name, which is a filename collision and which is why the
> >> bison++ package conflicts with the bison one.
> >>
> >> Now the bison executable in the bison++ package is byte-for-byte
> >> identical with the bison++ executable. I don't know why it's provided as
> >> an executable and not as a symbolic link, but it isn't and that's the
> >> reason why the packages conflict.
> > 
> > It is a mistake.  The Makefile for the bison++ package does not create the
> > bison executable.  The packacging creates the extra executable (and man page).
> > *That* is the bug.  It is unnecessary and unneeded.
> > 
> >>
> >>>
> >>>>
> >>>> Unlikely to get traction with Ubuntu bug tracker since the package lives
> >>>> upstream in Debian and also conflicts with the bison package there too.
> >>>> Looking at its changelog it seems to be in maintenance mode and its
> >>>> development appears to have halted in the mid-90's.
> >>>>
> >>>
> >>> I guess I will need to download the sources for both packages and fix them
> >>> myself.  (Unless there is a "trick" to tell apt to ignore the conflict.)
> >>>
> >> There's the "--force-conflicts" option for dpkg that will install a
> >> package despite its conflicting with another and overwriting the other's
> >> files. However, apt will complain about broken packages installed and
> >> likely won't allow any changes to the package database until the
> >> situation is fixed.
> >>
> >> You wouldn't need to build both packages from source, just one. You
> >> could install the regular bison package from the main repo and then
> >> install bison++ to /usr/local. The bison executable from bison++ would
> >> be installed to /usr/local/bin and wouldn't conflict with the one from
> >> the bison package which would be in /usr/bin, You'd still want to rename
> >> or remove /usr/local/bin/bison because it would be found first in $PATH,
> >> but it wouldn't conflict upon installation.
> >>
> > 
> > I actually don't even need to do that. All I need to do is fix the file(s) in
> > the debian directory in the bison++ package to correct its error. Then I can
> > install the resulting bison++ deb file normally, putting bison++ in /usr/bin
> > and bison++.1 in /usr/share/man/man1/.
> > 
> 
> Well good it sounds like you got it sorted.
> 

I just wish that the package maintainer would apply this fix to the repo 
version so that when I update my system, I don't end up breaking my code 
building process (or to anybody else that tries to build my code).  It is such 
a simple and *trivial* fix and actually only needs to be done once.

-- 
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller at deepsoft.com       -- Webhosting Services