Control: tag -1 + pending Hi Elimar,
as mentioned in https://lists.alioth.debian.org/pipermail/pkg-lynx-maint/Week-of-Mon-20151123/000277.html I was thinking about uploading this change, too, since we have to go through the NEW queue anyways. So the current plan is: * One upload to experimental which needs to go through the NEW queue with all changes which would trigger a deviation via the NEW queue. This includes: * Renaming the source package from lynx-cur to lynx. * Split-off a lynx-common package. The latter is disputed among team-members, but if we just upload it to experimental, we have a real example to test it and we don't have to go through the NEW queue a second time, even if we decide to remove the lynx-common package again. For that I've applied your patch to my renaming-back branch. Because the package names changed since you wrote the patch, I had to slightly adjust it. I've also made the update of the Uploaders list a separate commit: https://anonscm.debian.org/cgit/pkg-lynx/lynx.git/commit/?h=renaming-back&id=99a670011009041ec8c792678c55705946532bc0 https://anonscm.debian.org/cgit/pkg-lynx/lynx.git/commit/?h=renaming-back&id=b020de1543695236caf03e6cc59a40bed1d94762 Elimar Riesebieter wrote: > please find attached patch to break out a lynx-cur-common package. > This package contains files shared by the lynx-cur package over any > arch available in Debian. Examples of such shared files are: > manpages, locale and mimetype definitions, and configuration files. > > Lintian won't note an "arch-dep-package-has-big-usr-share" anymore. > We'll save arround 1,1M per (arch-1). Around 2M (depands on arch) > are preserved for the binary package. > > Please check the patch before applying it to the git repo. I've found a few, mostly minor or at least very easy to fix issues and will fix them before applying the patch for the next upload to experimental (via NEW queue): > Although I have an alioth account I can't check in > https://alioth.debian.org/projects/pkg-lynx/. So I created the > attached git-diff. It would be a great pleasure if I could join the > team ;-) I've just added you. I actually was waiting for such an request via the Alioth web interface for that, but I learned recently that I can just enter a user name to add team members and don't need to rely on that they're applying via the webinterface. > +Package: lynx-cur-common I'm about to swap the lynx and lynx-cur packages, so the final package name will be lynx-common. > +Architecture: any That's actually counter-productive. The main reason to split up is to be able to say "Architecture: all" here. :-) > +Depends: ${misc:Depends}, > + ${shlibs:Depends} Accordingly ${shlibs:Depends} is no more needed here either as it's the result of gathering data from compiled binary files. > +Recommends: lynx-cur I'm not sure if this is helpful or not. lynx-common is useless without lynx, but then again the real relation is the other way round. > +Description: shared files for lynx-cur package > + In continuous development since 1992, Lynx sets the standard for > + text-mode web clients. > + . > + This package contains files shared by the lynx-cur package over any arch > + available in Debian. Examples of such shared files are: manpages, locale > and > + mimetype definitions, and configuration files. Hrm. I actually would put the mimetype definitions back into the lynx package as they refer to /usr/bin/lynx which is in there. And suddenly the Recommends above makes much more sense. :-) > Package: lynx-cur The first binary package inside debian/control has special meaning as some debhelper tools install stuff by default into the first binary package if no package was explicitly mentioned. I would have taken lynx (formerly lynx-cur) as that primary package. But then again this mostly affects files installed by dh_installdocs like debian/README.Debian and so on and they might be better suited in lynx-common indeed. Will experiment which way round seems to be easier. > Depends: ${misc:Depends}, > - ${shlibs:Depends} > + ${shlibs:Depends}, > + lynx-cur-common If we symlink /usr/share/doc/lynx to /usr/share/doc/lynx-common as suggested below, for copyright and license reasons, the dependency above needs to be versioned. But see below... > diff --git a/debian/lynx-cur.links b/debian/lynx-cur.links > new file mode 100644 > index 0000000..19d93ce > --- /dev/null > +++ b/debian/lynx-cur.links > @@ -0,0 +1,3 @@ > +/usr/share/doc/lynx-cur-common /usr/share/doc/lynx-cur […] > diff --git a/debian/rules b/debian/rules > index 3612909..7935a01 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -44,6 +44,8 @@ override_dh_auto_install: > cd debian/tmp/usr/share/lynx_help && rm -vf COPYING COPYHEADER > cd debian/tmp/usr/share/lynx_doc && rm -rvf CHANGES \ > COPYHEADER.asc COPYING COPYING.asc samples test > - > +override_dh_link: > + rm -rf debian/lynx-cur/usr/share/doc/lynx-cur > + dh_link > %: > dh $@ --parallel --with autotools_dev While this seems a good idea on a first glance (and was common practise in the past), it causes issues with BinNMUs (i.e. uploads which don't change the source code of a package, but just upload the same source package being recompiled against updated build-dependencies) since BinNMUs add a /usr/share/doc/$pkg/changelog.Debian.$arch.gz (so that /usr/share/doc/$pkg/changelog.Debian.gz is the same over all architectures). A common way to workaround this is to put just the bare minimum in files (i.e. the changelog) in there and make symlinks from $file to ../lynx-common/$file in all other cases. I'll try to get that working. What I changed so far: https://anonscm.debian.org/cgit/pkg-lynx/lynx.git/commit/?h=renaming-back&id=06929828fffe98931b574397d5416e2c40101b21 I'm surely too tired to do a proper upload now. Will do it within the next few days. Until then I can also test this package in real-life usage. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
