On Sat, Mar 5, 2022 at 8:31 AM Martin-Éric Racine <[email protected]> wrote: > > On Sat, Mar 5, 2022 at 7:09 AM Martin-Éric Racine > <[email protected]> wrote: > > > > On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R. <[email protected]> wrote: > > > > > > El 02/03/22 a las 19:10, Martin-Éric Racine escribió: > > > > On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine > > > > <[email protected]> wrote: > > > > > > > > > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. <[email protected]> > > > > > wrote: > > > > > > > > > > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió: > > > > > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > * Could you please fix the indentation of the your new > > > > > > > > > > entry in d/copyright? > > > > > > > > > > > > > > > > > > IMHO, the whole file's indentation needs to be fixed. I had > > > > > > > > > troubles > > > > > > > > > aligning my addition, because the file currently uses > > > > > > > > > TAB+2SPACES. > > > > > > > > > There really should be a linting tool for that. > > > > > > > > > > > > > > > > Actually, it seems that wrap-and-sort can be used for > > > > > > > > d/copyright too. > > > > > > > > I somehow was under the impression that it's only used for > > > > > > > > d/control. > > > > > > > > I'm extremely tempted to run it on the whole package. > > > > > > > > > > > > > > Reading back on Bug #964947, I notice that the request was for > > > > > > > both > > > > > > > packaging current upstream and dropping the 5 out of the package > > > > > > > name. > > > > > > > I would tend to agree. The 5 really only was meant as an upstream > > > > > > > branch tag. The source and binary really should be called > > > > > > > 'dhcpcd' > > > > > > > since it essentially is a fork of the abandoned source of the same > > > > > > > name. > > > > > > > > > > > > Changing the source name means creating (or reintroducing) a > > > > > > different > > > > > > debian package. Just in case: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 > > > > > > > > > > > > Changing the binary name only means it would have to pass by NEW… > > > > > > > > > > Merely changing the binary name sounds perfectly reasonable to me. > > > > > > > > Please note that I have re-uploaded the package to Mentors. The log > > > > file is more explicit about cosmetic changes and about ./configure > > > > caveats. > > > > > > * Are you sure about this in debian/rules? > > > > > > + --libdir=/usr/lib/i386-linux-gnu \ > > > > > > At a first glance, I suppose that would break multiarch support. > > > > Without it, the udev backend goes in /lib, instead of /usr/lib like > > the rest of the package. It's in the changelog: --prefix somehow > > doesn't propagate as it should for --libdir and --mandir. > > Wait. I get what you meant. This ends up hard-coding the path on all > arch. Not good. > > This being said, I'm not sure of how else to fix the broken --prefix > propagation for --libdiir and --mandir. Finding and fixing the issue, > and possibly submiting a patch to upstream, requires more autotool > skills than I have.
Fixed. I found a kludge to poll dpkg for the target triplet. This still doesn't resolve the issue of why --prefix doesn't correctly propagate to --libdir and --mandir out of the box. Neither of these should need to be manually specified if --prefix propagates. Upstream's ./configure script probably is broken in some way. Martin-Éric
