Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Fri, Jun 8, 2012 at 6:17 PM, Philipp Kern wrote: On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: Does this mean M-A:same packages should be prevented from being binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO at most important, not serious. Possibly we could allow one last sourceful upload when the transitions all settled, but it would again increase the review load on the release team. IMHO it's on the if it works, fine, if not, sorry about that part of the list, given that it was finalized so late, with that critical piece missing. Wouldn't the ideal solution be non-architecture-specific changelogs? So, a normal binnmu changelog looks like this now: package (version) sid; urgency=low * Binary-only non-maintainer upload for amd64; no source changes. -- amd64 Builddd Daemon (barber) buildd_amd64-bar...@buildd.debian.org Tue, 05 Jun 2012 16:33:05 + which could be changed to something like this instead: package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-rele...@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpzr8wmwtrg4geqe5tscxhavcbiceny1wnp0zutf_c...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
Michael Gilbert mgilb...@debian.org (14/06/2012): package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-rele...@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. No, binNMUs numbers can be different, along with timestamps (even with: “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed one after each other). Also, reasons can be different. Mraw, KiBi. signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 12:40 PM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (14/06/2012): package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-rele...@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. No, binNMUs numbers can be different, along with timestamps (even with: “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed one after each other). Also, reasons can be different. Right, I imagine it will involving reworking of quite a few steps in the process, and again this would be only for 'multi-arch: same'. So, instead of the buildd (or wherever that is done now) creating the changelog/timestamp, instead create one 'multi-arch: same' changelog before passing it off to the buildds, and then after the build is done, replace the automatically architecture-specific changelog with the 'multi-arch: same' one. The reason for rebuilding a 'multi-arch: same' package by definition should be for the same reason on all architectures, right? Non 'multi-arch: same' binnmus would not need to change. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mpnlz6gvczq2scfyzvzu_qvtn_s9ab7+i9kbjozled...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: Wouldn't the ideal solution be non-architecture-specific changelogs? No, that would be very much non-ideal. One should be able to schedule binNMUs for a subset of archs, and one shouldn't have to look up whether a package builds m-a:same binaries. This has been said a few times already, please drop this thread if you're just going to repeat old shot-down ideas. Thanks, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120614170704.gz12...@radis.cristau.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 1:07 PM, Julien Cristau jcris...@debian.org wrote: On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: Wouldn't the ideal solution be non-architecture-specific changelogs? No, that would be very much non-ideal. One should be able to schedule binNMUs for a subset of archs, I did not suggest that. Anyway, maybe this will be a bit clearer. Let's say an existing package is at version +b1 on amd64, and it needs to get a binnmu, then a +b2 package is built on amd64, its changelog is taken and stuffed it into all of the other 'Multi-Arch: same' +b1 packages, which are now called +b2, and all of them uploaded. Those other architectures didn't undergo a rebuild, but nevertheless, they got new packages. Then lets say a +b3 is needed on i386, then the same is done, and the 'Multi-arch: same' amd64 package (and others) get stuffed with the i386 +b3 changes (which includes the prior amd64 +b2 changelog). and one shouldn't have to look up whether a package builds m-a:same binaries. This is a new special case that will need to be handled somehow, right? Look-ups are not that expensive; although admittedly the time spent writing the infrastructure supporting may not be. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MM=NcxfT-kRLtXoA_7_nX+mJRrxW+4vc7eZYenwSn3=u...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote: I did not suggest that. Anyway, maybe this will be a bit clearer. Let's say an existing package is at version +b1 on amd64, and it needs to get a binnmu, then a +b2 package is built on amd64, its changelog is taken and stuffed it into all of the other 'Multi-Arch: same' +b1 packages, which are now called +b2, and all of them uploaded. For various reasons you cannot do that without a rebuild. (Hint: Files must not change, new versions have their versions in various fields.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 3:43 PM, Philipp Kern wrote:
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote:
I did not suggest that. Anyway, maybe this will be a bit clearer.
Let's say an existing package is at version +b1 on amd64, and it needs
to get a binnmu, then a +b2 package is built on amd64, its changelog
is taken and stuffed it into all of the other 'Multi-Arch: same' +b1
packages, which are now called +b2, and all of them uploaded.
For various reasons you cannot do that without a rebuild. (Hint: Files must
not
change, new versions have their versions in various fields.)
Right, there is that additional complexity, but even so I think it
could be made to work.
dpkg-gencontrol could be used to update the Version and any
${binary:Version} fields in the control file. Also, the package's
md5sums could be regenerated to include the hash for the new
changelog.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=MNn+1jxCbf_Gj=g2dH=meooxfggxz+iduge5dopzzd...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Mon, 2012-06-11 at 11:39:24 +0100, Ian Jackson wrote: Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. Well, the dpkg suite makes extensive use of the changelog to retrieve all kinds of information, dpkg (the program) does not currently access it though, but that data is still package metadata. The same could be said about some fields in the control file and it still makes sense to have them there, because again it's package metadata. There's also other precedent of package metadata not handled directly by dpkg (currently or in the past) which gets installed in the info database, like templates, config, md5sums and clilibs, for some I'm aware of. I disagree placing it in the dpkg database is not helpful, for a user or other programs wanting to access that structured package metadata it's obviously easier and better to do something like «dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog», than having to go hunt where in the filesystem the changelog might be located, regardless of distribution path polcies. The same for the copyright information, and I've actually been asked in the past why dpkg does not have a command to show package copyright information. I've listed the other reasons (which you trimmed) in the parent mail. And if by “the binNMU changelogs”, you mean the split changelog solution, I still disagree that's the correct avenue. It means the information of why the package was rebuilt either ends up in yet another different place on the filesystem, or lost if the helper does not get updated to cope with that or if the package does not use any helper, which is still a non-insignificant amount of the archive. It might also break with packages poking at the debian/changelog file directly as Jonathan mentioned, or external software accessing the source tree, because debian/changelog is an interface, and while it might seem like a straightforward solution it looks like it will cause more problems than the ones it solves, and it still seems like a workaround. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... This path leads, eventually, to all structured data currently stored in the filesystem being subsumed by dpkg. This is not healthy for dpkg and not healthy for the rest of the project. Eh, only structured data that is packaging metadata. TBH, I don't see other clear candidates besides changelog and copyright (maybe even NEWS.Debian, but this one might be a stretch), and those two are clearly package metadata. So, I'm still unconvinced by the arguments you brought up. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612065943.ga19...@gaara.hadrons.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sun, Jun 10, 2012 at 10:01:29AM +0200, Guillem Jover wrote: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. At last. I've always thought having changelog and copyright in /usr is incorrect and they belong with other metadata. And when I saw discussions about M-A and binNMUs I've instantly understood that it is the real solution for that problem. I'm not sure about as long as it's in machine parseable format though. (maybe we'll get signed .debs and other RPM goodies one day too) -- WBR, wRAR signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Ian Jackson (ijack...@chiark.greenend.org.uk) [120611 13:21]: Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. Hm. Though I see the reasoning in general, would you think it hurts to have the binary epoch (and the corresponding binNMU reason) be stored in the metadata instead of the changelog as today? Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612185205.gn13...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120612 09:00]: I disagree placing it in the dpkg database is not helpful, for a user or other programs wanting to access that structured package metadata it's obviously easier and better to do something like «dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog», than having to go hunt where in the filesystem the changelog might be I don't see why dpkg --show-changelog foo can't work even if the changelog is stored in the filesystem. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612185352.go13...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMUbroke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... This path leads, eventually, to all structured data currently stored in the filesystem being subsumed by dpkg. This is not healthy for dpkg and not healthy for the rest of the project. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20437.51932.971859.384...@chiark.greenend.org.uk
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote: * Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. Just that this won't do it, because the changelogs for the different arches will be binary different, so no win. However, we discussed that during the multi-arch bof last Debconf, and came to the conclusion that it would be better to not modify the changelog as we do now, but instead create a new file changelog.$arch.$version with the binNMU. This is a bit more complicated because it can't be done as of now just within the source package. As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. This has (at least) the following advantages: * no need to concat different files to get the complete changelog. * the version in the changelog would match the package binary version. * the changelog file would *always* get to be referred by the same name regardless of the package being native, binNMUed or otherwise. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... * dpkg can gain new commands to return/show these files reliably w/o needing (eventually) to hardcode the distribution's specific path (which is a matter of fileystem policy dpkg does not really need or has to know). * dpkg eventually could do a way better job at reducing duplicated data, by for example transparently hardlinking them, instead of our ad-hoc doc dir symlinking. * dpkg could reduce space usage by transparently compressing them with something better than gzip. * (minor) it's a common pattern to want to exclude all of /usr/share/doc/pkg but the copyright file, storing it elsewhere would avoid that. To that end, last month I cooked a preliminary patch for dpkg to add two new commands: --show-changelog and --show-copyright, that take a package name and print to stdout (through a pager if on a terminal) either of those files, and fallback to a configurable set of paths on the filesystem if the requested file is not in the database (decompressing them if need be). regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120610080128.ga8...@gaara.hadrons.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120610 10:08]: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I'm fully happy to see that solved in whatever way. However, getting it sorted out for binNMUs seems like some kind of priority to me. Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120610115223.gy2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote: Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. There is no such block in place. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Philipp Kern (pk...@debian.org) [120610 14:06]: On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote: Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. There is no such block in place. No, just the package won't be co-installable afterwards. Which doesn't make me really happy. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120610213624.gz2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. Just that this won't do it, because the changelogs for the different arches will be binary different, so no win. However, we discussed that during the multi-arch bof last Debconf, and came to the conclusion that it would be better to not modify the changelog as we do now, but instead create a new file changelog.$arch.$version with the binNMU. This is a bit more complicated because it can't be done as of now just within the source package. Anyone implementing this is warmly welcome. Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120609132606.gx2...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: Does this mean M-A:same packages should be prevented from being binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO at most important, not serious. Possibly we could allow one last sourceful upload when the transitions all settled, but it would again increase the review load on the release team. IMHO it's on the if it works, fine, if not, sorry about that part of the list, given that it was finalized so late, with that critical piece missing. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 9, 2012 at 6:17 AM, Philipp Kern pk...@debian.org wrote: On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: Does this mean M-A:same packages should be prevented from being binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO at most important, not serious. Possibly we could allow one last sourceful upload when the transitions all settled, but it would again increase the review load on the release team. OK, I get your point, and I never meant not to binNMU is a reasonable idea. The reason for RC severity is just to prevent the version from migrating to testing before I've sorted out the M-A mess as much as possible on my side - for example #671902. Also, there is no important user-sensible changes (package maintainers and users) in this version, but mostly improvements to maintainability. IMHO it's on the if it works, fine, if not, sorry about that part of the list, given that it was finalized so late, with that critical piece missing. Sure, I'll get the final version into archive before freeze, regardless whether there are remaining odd bits of M-A as long as they aren't affecting normal users. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4f6buu_jvruta8d9d1m0tcnmkonub3qsh4f4v-mlv...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, 09 Jun 2012, Philipp Kern wrote: On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: Does this mean M-A:same packages should be prevented from being binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO Indeed, we cannot. But there has never been a need to, anyway. We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. This is even listed in Ubuntu's MultiarchSpec wiki package... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120609003040.ga13...@khazad-dum.debian.net
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, Jun 9, 2012 at 8:30 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Sat, 09 Jun 2012, Philipp Kern wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool. Also multiarch bugs are
IMHO
Indeed, we cannot. But there has never been a need to, anyway.
We'd just have to teach the tool to binNMU all arches when the target
package would need it due to multiarch. Release team requests a binNMU of a
package for some arch, the tool notices it has to do them all because of
multi-arch constraints, and replicates the request for all other arches.
This is even listed in Ubuntu's MultiarchSpec wiki package...
Yes, but things are a little bit different here. I did request binNMUs
of all archs, but unfortunately buildds of every architecture
generates a unique changelog entry saying the NMU is done by ${arch}
architecture buildd admin, and you already know what would happen, :)
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMr=8w6LoQHqjaBXb-V0z_-_4K=ZbE7MEVA8Yp9SZQ½rr...@mail.gmail.com
