On Mon, Aug 17, 2009 at 7:01 AM, Niko Tyni<nt...@debian.org> wrote: >> There are ways around that, have the perl package provide a name which >> maps to the debian version less NMUs (either by manually updating >> debian/control, or an automated process which removes bin NMUs from >> the version). > > As binNMUs get an extra changelog entry compared to their arch:all > counterparts, all approaches that try to make them equivalent seem > fundamentally broken to me. But maybe I'm just misunderstanding you.
I was suggesting: Package: perl Provides: perl-${debian-base:Version} Package: perl-modules Depends: perl-${debian-base:Version} or something similar, and to have debian-base:Version set by debian/rules to be the Debian version =~ s/\+b\d+$// This would mean that arch-indep packages may have a changelog which contains one or more binary NMU lines that technically do not apply, but as these are machine generated metadata do we really care? >> Another alternative, certainly the simplest, would be to remove >> perl-modules entirely and have those arch-indep parts included in the >> perl package. [...] > I find this suggestion somewhat appealing, particularly as it would > remove the dependency loop that people frequently complain about > (#527917 / #502455) and simplify major version upgrades. > > The size of the packages is roughly > package size installed-size > perl 5M 15M > perl-modules 3M 15M > > so with ~15 architectures, the join would take on the order of 50 > megabytes more mirror space per suite, altogether something like 200 > megabytes. That does sound a bit much, but OTOH it's less than .1 % > of the total archive size. Note that while size in the archive was part of the original motivation of splitting the arch-indep parts out, it also seemed to be the correct thing to do in so far as making scenarios such as described in the FHS easier to manage (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA). Having said that, I'm inclined to believe that merging the two is perhaps the best course. > A quick count shows 116 packages in sid that have a versioned dependency > (build- or otherwise) on perl-modules. Those would have to be fixed > first unless we provided a transitional empty perl-modules package. My inclination would be to have an empty package. > In any case, the join wouldn't solve the issue this bug is about > completely, as perl-doc also has an arch:all->arch:any symlink in > /usr/share/doc. It therefore seems to me that a possible perl/perl-modules > join is a separate matter and should not necessarily be coupled with > this bug. This similarly could be solved with the provides/dependency as described above. > I think removing the symlinks with maintainer scripts and separating > the /usr/share/doc entries is the best course of action here. Sure. I would still be inclined to keep the majority of the documentation under /usr/share/doc/perl (as it is currently), and merely have copies of changelog.Debian.gz, copyright and perhaps a short README.Debian in /usr/share/doc/perl-doc. If, OTOH you think that it would be clearer to split the docs across perl-base, perl and perl-doc, I can take a look at what machinations would be required to apply that on update. --bod -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org