On Wed, 4 Nov 2009 15:20:31 +0100
Hector Oron hector.o...@gmail.com wrote:
Hello,
2009/11/4 Goswin von Brederlow goswin-...@web.de:
Neil Williams codeh...@debian.org writes:
While being highly interesting talk to me, this discussion is no
relevant to the ITP. I would suggest to either
Bastian Blank wa...@debian.org writes:
What happens if someone install libc-bin without a new libc6 then?
At present, I would expect that to run into file conflicts with
libc6. In the future, yes, that could be a problem without
appropriate Breaks: or Conflicts: declarations. :-/
One possible
with *-dbg flavour or .ddeb can be
Multi-Arch: foreign, which put a serious dampner on multiarch
functionality.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Mon, Aug 03, 2009 at 02:02:24AM +0200, Aurelien Jarno wrote:
I have finally decided to remove the Depends: line in libc-bin, even if
I don't really like that. My tests show that it works now, but don't
hesitate to test it on your machine.
What happens if someone install libc-bin without a
Bastian Blank a écrit :
On Mon, Aug 03, 2009 at 02:02:24AM +0200, Aurelien Jarno wrote:
I have finally decided to remove the Depends: line in libc-bin, even if
I don't really like that. My tests show that it works now, but don't
hesitate to test it on your machine.
What happens if someone
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote:
Bastian Blank a écrit :
What happens if someone install libc-bin without a new libc6 then?
Forgot about that variant before as it is not forbidden by deps now.
If it is not the same major version, it will probably break, I'll
Bastian Blank wa...@debian.org writes:
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote:
Bastian Blank a écrit :
What happens if someone install libc-bin without a new libc6 then?
Forgot about that variant before as it is not forbidden by deps now.
If it is not the same
Goswin von Brederlow goswin-...@web.de (03/08/2009):
Does it break aptitude too?
I think that people involved in serious things like multiarch and glibc
might appreciate your staying quiet at some point given the quite huge
mess you initially created. But maybe that's just me.
Mraw,
KiBi
Cyril Brulebois k...@debian.org writes:
Goswin von Brederlow goswin-...@web.de (03/08/2009):
Does it break aptitude too?
I think that people involved in serious things like multiarch and glibc
might appreciate your staying quiet at some point given the quite huge
mess you initially created
On Mon, Aug 03, 2009 at 09:21:53PM +0200, Goswin von Brederlow wrote:
Bastian Blank wa...@debian.org writes:
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote:
Bastian Blank a écrit :
What happens if someone install libc-bin without a new libc6 then?
Forgot about that
On Tue, Aug 04, 2009 at 02:05:22AM +0200, Goswin von Brederlow wrote:
Cyril Brulebois k...@debian.org writes:
Goswin von Brederlow goswin-...@web.de (03/08/2009):
Does it break aptitude too?
I think that people involved in serious things like multiarch and glibc
might appreciate your
to experimental to fix that.
eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
mirrors soon. Please test and report problems.
It still fails in my Lenny chroot:
I have finally decided to remove the Depends: line in libc-bin, even if
I don't really like that. My
-dev-powerpc libc6-ppc64 libc6-dev-ppc64
libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386
libc0.1-dev-i386 libc6-sparcv9b libc6-i686 libc6-xen libc0.1-i686
libc6.1-alphaev67 libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.9-23+multiarch.2
in the resulting deb. Not who has to make
those changes. Things like debhelper and cdbs will hopefully automate
some things. I could imagine that you could have the following rules
file:
#!/usr/bin/make
%:
dh --with multiarch $@
or at some point --with multiarch would be default.
I would still want
I would still want that multi-arch dependencies would be specified at
one straight place, not two.
For most things it will be the depended on package. Your suggestion
would make it always be in 2 places (co-installability in the library,
depends in the dependee). I think the proposed way
On Thu, Jul 30, 2009 at 06:02:29PM +0200, Aurelien Jarno wrote:
We have the constraints that we should support upgrades from Lenny, so
we are stuck with apt/aptitude from lenny...
Remove the dependency from libc-bin. As long a libc-bin does not have
maintainer scripts, this should work.
.
I also think that -dbg packages are a wart on our archive and our packaging,
and am not overly concerned about whether these packages remain consistent
on transition to multiarch - unlike interpreters, which need to be handled
right for the sanity of our users.
Another option would
On Fri, Jul 31, 2009 at 12:22:02PM +0200, Bastian Blank wrote:
On Thu, Jul 30, 2009 at 06:02:29PM +0200, Aurelien Jarno wrote:
We have the constraints that we should support upgrades from Lenny, so
we are stuck with apt/aptitude from lenny...
Remove the dependency from libc-bin. As long a
On Wed, Jul 29, 2009 at 11:30:33PM +0200, Goswin von Brederlow wrote:
Moreover, this is not the only exception. Thousands of desktop and server
packages that contains executable binaries (applications) compiled from
C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
Goswin von Brederlow goswin-...@web.de (29/07/2009):
Thoughts from the maintainer?
You may want to read #468209, which is kind of related.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Charles Plessy ple...@debian.org (30/07/2009):
I have three questions about Multi-arch:
1) […]
2) […]
3) Where is the third question? :)
Mraw,
KiBi.
signature.asc
Description: Digital signature
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right
You'll have to do it sooner or later. At least for
Charles Plessy, le Thu 30 Jul 2009 13:13:59 +0900, a écrit :
1) What is the advantage of adding a new field over simply using something
like
‘Arch: multi’?
Err, I believe it makes sense to mark an i386/amd64-only library as
multiarch-capable.
Samuel
--
To UNSUBSCRIBE, email to debian
of the .pc file. Removing the ifdef would also enable
this on Linux and make pkg-config multiarch-usable.
Alternative: install pkg-config as ${DEB_HOST_GNU_TYPE}-pkg-config for
each arch (each with the correct default search path) and link the
default arch pkg-config to it. Autotools
it's not a problem.
Change PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR instead.
Don't ask the user to do it ;)
pkg-config has a win32-only feature to derive the prefix variable from
the location of the .pc file. Removing the ifdef would also enable
this on Linux and make pkg-config multiarch
On Wed, 29 Jul 2009, Goswin von Brederlow wrote:
However, you *can* share the same .mo files on each platform, since the
gettext code copes with endianness issues at runtime if need be.
So we would have to define a default endianness for creating such
files. A patch to gettext to create
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right
the *rationale* for
multiarch handling /usr/share in a way that doesn't require splitting out
common packages, but dpkg will not handle /usr/share/doc differently than
any other files.
Well, the execption is for /usr/share. So locale, docs, whatever is
covered there.
MfG
Goswin
Charles Plessy ple...@debian.org writes:
Le Wed, Jul 29, 2009 at 03:57:31PM +0200, Goswin von Brederlow a écrit :
I got some good feedback from my previous Introduction to multiarch
post and some good questions. I'm singling out Manoj Srivastava here
because he was the most recent to ask
On Thu, Jul 30, 2009 at 11:04:46AM +0200, Samuel Thibault wrote:
Yes, but however pkg-config won't yet find things in
/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
in /usr/lib/pkgconfig.
$ pkg-config --list-all --debug
[...]
Cannot open directory
On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:
On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
In short it looks like a Pre-Depends is overkill, and that a Depends is
enough. I'll upload a new version soon to experimental to fix that.
eglibc version 2.9-23+multiarch.1
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary
to experimental to fix that.
eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
mirrors soon. Please test and report problems.
It still fails in my Lenny chroot:
,
| # LANG=C apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree
Aurelien Jarno wrote:
Except saying apt sucks, I currently do not have more idea. Someone
else maybe?
/me suggests to try cupt and hides
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital
archive and our packaging,
and am not overly concerned about whether these packages remain consistent
on transition to multiarch - unlike interpreters, which need to be handled
right for the sanity of our users.
Another option would be for foo to
Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version
On Thu, Jul 30, 2009 at 06:58:45PM +0300, Eugene V. Lyubimkin wrote:
Aurelien Jarno wrote:
Except saying apt sucks, I currently do not have more idea. Someone
else maybe?
/me suggests to try cupt and hides
We have the constraints that we should support upgrades from Lenny, so
we are
]]
| My first thought was Err. Won't moving all the shared libs into a
| different location kinda screw things up? And then I looked, and found
|
|| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
|
| Yes, but however pkg-config won't yet find things in
|
]] Gabor Gombas
| Later pkg-config should be extended to have an --arch command-line
| option (or env. variable) that is substituted into the default search
| path at run time rather than at build time, but that can wait.
This has been considered before, and I'm not yet convinced it's a better
On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:
I have recently uploaded to experimental eglibc 2.9-23+multiarch, from
our multiarch branch. It doesn't use the multiarch paths yet, but it is
a first step toward multiarch.
The only difference with the unstable version is that libc-bin
. This way it
complies with the Debian Policy requirement that the libraries should
not contain binaries, which is also a requirement for multiarch.
I just tried to upgrade libc6 with experimental. The upgrade has been
smooth but libc-dev-bin has not been pulled in (whereas libc6-dev has been
Hi,
I got some good feedback from my previous Introduction to multiarch
post and some good questions. I'm singling out Manoj Srivastava here
because he was the most recent to ask this on irc but there where
others with the same or simmilar question.
The full multiarch proposal can be read
On Wed, Jul 29, 2009 at 01:56:40PM +0200, Sven Joachim wrote:
On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:
I have recently uploaded to experimental eglibc 2.9-23+multiarch, from
our multiarch branch. It doesn't use the multiarch paths yet, but it is
a first step toward multiarch
Hi,
small add on.
Any package in debian can be multiarchified at any time. You do not
have to wait for all your depends to be multiarchified or notifiy your
reverse depends when you are ready. The state of your depends will
only matter when someone actualy does a multiarch installation and
apt
someone actualy does a multiarch installation and
apt/dpkg will figure out by themself if all the depends are ready or
not. The current apt/dpkg will just ignore the multiarchifying.
Multiarchifying your package does not hurt the installability in any
way. It can only help.
My first
My first thought was Err. Won't moving all the shared libs into a
different location kinda screw things up? And then I looked, and found
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
Yes, but however pkg-config won't yet find things in
/usr/lib/x86_64-linux-gnu/pkgconfig, so take
. The state of your depends will
only matter when someone actualy does a multiarch installation and
apt/dpkg will figure out by themself if all the depends are ready or
not. The current apt/dpkg will just ignore the multiarchifying.
Multiarchifying your package does not hurt the installability
does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
it is specific to the soname) - but it sounds like that will break
library multiarch too. Can we have an exception for this? It seems
silly to require a libfoo0-l10n package for every localized library.
--
Peter Samuelson | org-tld
(/usr/share/doc/package/ is excempt and dpkg will handle that).
Policy does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
it is specific to the soname) - but it sounds like that will break
library multiarch too. Can we have an exception for this? It seems
silly to require
sthiba...@debian.org writes:
My first thought was Err. Won't moving all the shared libs into a
different location kinda screw things up? And then I looked, and found
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
Yes, but however pkg-config won't yet find things in
On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
My first thought was Err. Won't moving all the shared libs into
a different location kinda screw things up? And then I looked, and
found
,
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
| # Multiarch support
Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
the only requirement is that any files shipped there are identical
between packages of the same version for multiple architectures.
That's however not true for .mo files, for endianness, typically.
Samuel
--
To UNSUBSCRIBE, email
Goswin von Brederlow, le Wed 29 Jul 2009 19:09:59 +0200, a écrit :
sthiba...@debian.org writes:
My first thought was Err. Won't moving all the shared libs into a
different location kinda screw things up? And then I looked, and found
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
Hi Goswin, hi -devel,
I would somewhat object to Multi-Arch field in the long run, and here are my
thoughts.
What the multiarch spec proposes now is package-oriented approach: the package
should define whether it is 'same' or 'foreign' kind. This is not
straightforward, because in fact
this mean for /usr/share/locale and multiarch? Do we need
to move to /usr/lib/{gnu-type}/locale?
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
however not true for .mo files, for endianness, typically.
So what does this mean for /usr/share/locale and multiarch? Do we need
to move to /usr/lib/{gnu-type}/locale?
My understanding is that .mo files include an endianness tag, so files of
either endianness can be loaded on any system
Hi Eugene,
On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
Moreover, this is not the only exception. Thousands of desktop and server
packages that contains executable binaries (applications) compiled from
C/C++/Pascal/etc. also have arch-dependent reverse dependencies -
arch-dependent reverse dependencies - packages
with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.
First, why do these packages need to be cross-installed?
If Debian is going to adopt multiarch, the spec should cover all packages.
Well... here is: one of multiarch stories
Peter Samuelson, le Wed 29 Jul 2009 13:41:20 -0500, a écrit :
Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
the only requirement is that any files shipped there are identical
between packages of the same version for multiple architectures.
[Samuel Thibault]
That's
.
Samuel
Any of the lintian people reading this?
Could we create a check for *.pc files that they are in the right
place and right package in anticipation of multiarch? Wrong package
already is a bug and wrong place seems to be a likely bug to happen.
MfG
Goswin
--
To UNSUBSCRIBE, email
On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
In short it looks like a Pre-Depends is overkill, and that a Depends is
enough. I'll upload a new version soon to experimental to fix that.
eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
mirrors soon
Samuel Thibault sthiba...@debian.org writes:
Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
the only requirement is that any files shipped there are identical
between packages of the same version for multiple architectures.
That's however not true for .mo files, for endianness,
of multiarch? Wrong package
already is a bug and wrong place seems to be a likely bug to happen.
Could you file a bug against lintian so that we don't lose track?
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ
Discussions should probably go to debian-dpkg.
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
Hi Goswin, hi -devel,
I would somewhat object to Multi-Arch field in the long run, and here are my
thoughts.
What the multiarch spec proposes now is package-oriented approach: the package
. .ddeb packages would be a
solution benefiting users, multiarch and the archive and mirrors in
the long run. Till then -dbg packages can be detected by name in the
worst case.
Second, why does the Multi-Arch: allowed option not implement what you need?
It seems ok to me if Multi-Arch: allowed
-linux-gnu.conf ==
| # Multiarch support
| /lib/x86_64-linux-gnu
| /usr/lib/x86_64-linux-gnu
| __ dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
| libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
`
side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list
Hi gettext,
while talking about multiarch the issue was raised that
/usr/share/locale/*/*package.mo
is not identical across all architectures as multiarch would require.
Russ Allbery r...@debian.org writes:
Samuel Thibault sthiba...@debian.org writes:
Steve Langasek, le Wed 29 Jul 2009 19
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
What the multiarch spec proposes now is package-oriented approach: the
package
should define whether it is 'same' or 'foreign' kind. This is not
straightforward, because in fact not the package decides it's
and right package in anticipation of multiarch? Wrong package
already is a bug and wrong place seems to be a likely bug to happen.
Could you file a bug against lintian so that we don't lose track?
Done.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
up? And then I looked, and
found
,
| == /etc/ld.so.conf.d/x86_64-linux-gnu.conf ==
| # Multiarch support
| /lib/x86_64-linux-gnu
| /usr/lib/x86_64-linux-gnu
| __ dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
| libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
`
side
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
Goswin von Brederlow wrote:
Eugene V. Lyubimkin jackyf.de...@gmail.com writes:
What the multiarch spec proposes now is package-oriented approach: the
package
should define whether it is 'same' or 'foreign' kind. This is not
straightforward
[Goswin von Brederlow]
3) Library package
--
a) Follow Policy 8.2 (MUST directive)
No conffiles, no binaries in the library package, no shared files
(/usr/share/doc/package/ is excempt and dpkg will handle that).
We have mostly settled the /usr/share/locale
On Wed, Jul 29, 2009 at 07:38:22PM -0500, Peter Samuelson wrote:
We have mostly settled the /usr/share/locale question, and apparently
/usr/share/doc is a special exception anyway
No, it is not. The ubiquity of /usr/share/doc provides the *rationale* for
multiarch handling /usr/share
Le Wed, Jul 29, 2009 at 03:57:31PM +0200, Goswin von Brederlow a écrit :
I got some good feedback from my previous Introduction to multiarch
post and some good questions. I'm singling out Manoj Srivastava here
because he was the most recent to ask this on irc but there where
others
-dev-powerpc libc6-ppc64 libc6-dev-ppc64
libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386
libc0.1-dev-i386 libc6-sparcv9b libc6-i686 libc6-xen libc0.1-i686
libc6.1-alphaev67 libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.9-23+multiarch.1
Hi Goswin,
On Sat, Jul 25, 2009 at 11:57:12PM +0200, Goswin von Brederlow wrote:
So I decided to write an introduction to the problem that focuses more
on the user side, why we want multiarch at all, what goals and
requirements are to be met and gives some pointers.
Thanks for this. I'm
Steve Langasek vor...@debian.org writes:
Hi Goswin,
On Sat, Jul 25, 2009 at 11:57:12PM +0200, Goswin von Brederlow wrote:
4) Implementation (migration)
For most users activating multiarch would be a simple matter of
putting
Apt::Architectures {amd64; i386;};
in /etc/apt/apt.conf.d
without.
If the admin runs dpkg -i
foo_i386_1.2-3.deb on amd64 then I assume he does want that i386 deb
even if he hasn't configured multiarch for everything. I don't think
dpkg should block that.
Yep. dpkg also don't consider several relations, apt considers
Hi all,
I have recently uploaded to experimental eglibc 2.9-23+multiarch, from
our multiarch branch. It doesn't use the multiarch paths yet, but it is
a first step toward multiarch.
The only difference with the unstable version is that libc-bin and
libc-dev-bin are splitted out of libc6
for multiarch.
I just tried to upgrade libc6 with experimental. The upgrade has been
smooth but libc-dev-bin has not been pulled in (whereas libc6-dev has been
upgraded). Is it the expected behavior ?
$ sudo apt-get install -t experimental libc6
Lecture des listes de paquets... Fait
Construction de l'arbre
should
not contain binaries, which is also a requirement for multiarch.
I just tried to upgrade libc6 with experimental. The upgrade has been
smooth but libc-dev-bin has not been pulled in (whereas libc6-dev has been
upgraded). Is it the expected behavior ?
Thanks for noticing that. It's
-dev-powerpc libc6-ppc64 libc6-dev-ppc64
libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386
libc0.1-dev-i386 libc6-sparcv9b libc6-i686 libc6-xen libc0.1-i686
libc6.1-alphaev67 libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.9-23+multiarch
Hi,
Thanks for the introduction.
2009/7/25 Goswin von Brederlow goswin-...@web.de:
after listening to the Multiarch round table talk at Debconf I feel
that the talk was targeted at people already familiar with the subject
and jumped right in at full speed. Someone new to the idea
On Sat, Jul 25, 2009 at 11:57:12PM +0200, Goswin von Brederlow wrote:
Hi,
after listening to the Multiarch round table talk at Debconf I feel
that the talk was targeted at people already familiar with the subject
and jumped right in at full speed. Someone new to the idea was
probably lost
Hector Oron hector.o...@gmail.com writes:
Hi,
Thanks for the introduction.
2009/7/25 Goswin von Brederlow goswin-...@web.de:
after listening to the Multiarch round table talk at Debconf I feel
that the talk was targeted at people already familiar with the subject
and jumped right
Hi,
after listening to the Multiarch round table talk at Debconf I feel
that the talk was targeted at people already familiar with the subject
and jumped right in at full speed. Someone new to the idea was
probably lost in the first minute.
So I decided to write an introduction to the problem
Goswin von Brederlow goswin-...@web.de writes:
And why should there be. The package it totally usable and functional
as designed.
Does it properly support aptitude / synaptic / etc yet?
[The whole print a message on stdout telling the user he'd better do
something else thing was dodgy beyond
Miles Bader mi...@gnu.org writes:
Goswin von Brederlow goswin-...@web.de writes:
And why should there be. The package it totally usable and functional
as designed.
Does it properly support aptitude / synaptic / etc yet?
[The whole print a message on stdout telling the user he'd better do
?
Something can be a hack and still work. Imho it is the least ugly
thing to ties 32bit support over till actual multiarch happens.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Goswin von Brederlow goswin-...@web.de writes:
Does it properly support aptitude / synaptic / etc yet?
[The whole print a message on stdout telling the user he'd better do
something else thing was dodgy beyond belief, and clearly is not
acceptable for testing.]
Sure the support isn't
Hi,
Hans-J. Ullrich schrieb:
Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow:
The conversion system is an ugly hack. Sure. [...]
Despite whatever the people say, I like the new package. And I like the idea
behind it. And if it does not work at the beginning, who cares? It is
have uploaded it
to experimental.
As of now I see no such RC bug...
Regards
Micha
And why should there be. The package it totally usable and functional
as designed.
The only reason for it not to be in squeeze would be if multiarch
support will be in squeeze. Which I doubt will actually
would be if multiarch
support will be in squeeze. Which I doubt will actually happen.
I think we are yet faraway from last decisions on what is going to be
supported in squeeze and what not. So, IMHO it would be perfectly
reasonable to keep the package out of squeeze for now.
Once a package has
]] Yannick
| But then, why do some bother with multiarch implementation? ;-)
Because it solves the problem in a much more elegant way.
| Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32-
| apt-get but at the distribution level?
It accomplishes some of the same goals
Goswin von Brederlow wrote:
Bernd Zeimetz be...@bzed.de writes:
Goswin von Brederlow wrote:
and it has numerous RC bugs.
Lets see:
http://packages.qa.debian.org/i/ia32-libs-tools.html
RC bugs: 1
There were 6 bugs when I looked at the page before writing my mail, guess
you've
On Sun, Jul 05, 2009 at 10:41:10PM +0100, Roger Leigh wrote:
BTW, do you want a bug report about this against schroot?
Yes please! Since I have the memory of a goldfish, I can't forget
this way ;)
Done: #535943. I've tried to summarize the relevant points of this
design discussion; please
Bernd Zeimetz be...@bzed.de writes:
Goswin von Brederlow wrote:
Bernd Zeimetz be...@bzed.de writes:
Goswin von Brederlow wrote:
and it has numerous RC bugs.
Lets see:
http://packages.qa.debian.org/i/ia32-libs-tools.html
RC bugs: 1
There were 6 bugs when I looked at the page before
, that is meant to break in horrible
ways, has no forward upgrate path to a multiarch work, and so on.
If you really mean to provide something like ia32-apt-get, what you
ought to do is to:
- help the user create and maintain a proper 32bits chroot;
- let ia32-apt-get or whatever it's called
system is an ugly
hack, something completely horrible, that is meant to break in horrible
ways, has no forward upgrate path to a multiarch work, and so on.
The conversion system is an ugly hack. Sure. But it is the same ugly
hack 32bit support has always done, for over 5 years. The only change
it there only those things the user
needs/wants need converting and all the user needs/wants can be
converted. That is the big advantage of ia32-apt-get over ia32-libs.
If you find the conversion unacceptable then the only option for you
is to request 32bit support on amd64/ia64 is removed till multiarch
]] Yannick
| For instance, I wanted to test Firefox 3.5 in 32bits on my amd64
| Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript
| engine). With ia32-apt-get, I could install the 32bit version of my
| GTK theme engine so that Firefox can look good.
You could just use a
601 - 700 of 907 matches
Mail list logo
