There may have been some misunderstanding here? I believe Philipp and
Riku were interpreting this:
> This needs to be based on unreleased packaging which isn't anywhere
> public yet
as saying you had some semi-finished packaging which you wanted people
to rebase onto, but that they can't do so, because it isn't available to
them. If that's not it, could you please say what you'd prefer packages
to be relative to? Or, if they did understand correctly, could you
please make that packaging available somewhere so someone can help to
finish it, or prepare a patch that's more to your liking?
When changing someone else's package the typical assumption is that they
want you to start from the package's declared VCS or the last upload,
and make minimal changes. If that's not the case for zlib, fine, but
please say what starting point and which other changes you'd prefer to
have. (I infer from the discussion so far that "delete the Vcs-Bzr field
so people don't try to follow it" is one such change.)
On 07/02/12 11:13, Mark Brown wrote:
> we've had dpkg support for this in experimental for
> less than a week, it's not in unstable yet and you're upset that I've
> not been actively integrating this into unstable?
If you'd prefer experimental, that'd be good too. Having the library
appear in multiarch directories and work for the "main" architecture is
a significant step (and as far as I can see, in most cases, the only
step needed), even if it can't immediately be installed for two or more
architectures.
Multiarch-compatible libraries for the main architecture don't require a
multiarch dpkg, only a ld.so that loads from the multiarch-compatible
directories (available in its final form, AFAICS, since last June). In
some ways, the dependency relationship between multiarch dpkg and
multiarch libraries is closer to being the other way round: a multiarch
dpkg isn't useful (or testable without building local packages, i.e. by
the "random users" you mentioned) until there are (dependency chains of)
co-installable packages to install with it.
For instance, GLib in testing is already installed to multiarch
locations, as are all of its other dependencies. It works fine for a
single-architecture system, but it isn't actually possible to install a
second architecture of GLib right now, because they'd both require their
architecture's zlib, and zlib isn't yet in multiarch locations, so you
can only have it for one architecture.
Similarly, multiarch installability of libpng/testing is only waiting
for zlib, and gtk2/testing seems to only be waiting for zlib and cairo
if I'm reading aptitude correctly.
The patches proposed on this bug might not be perfect, but they're the
minimal change. Ubuntu's zlib has had basically the same patch for
almost a year (including 2 Ubuntu releases); I realise things in Ubuntu
aren't always held to the same standard as in Debian, but it's not as if
nobody has tried it.
S
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
