On Thu, Nov 01, 2012 at 09:37:22AM -0700, Thiago Macieira wrote: > On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote: > > > > > distributions should have *both*: > > > > > /usr/lib/qt5//bin/assistant AND > > > > > /usr/lib64/qt5/bin/assistant > > > > > /usr/lib/qt5//bin/linguist AND > > > > > /usr/lib64/qt5/bin/linguist > > > > > /usr/lib/qt5//bin/designer AND > > > > > /usr/lib64/qt5/bin/designer > > > > > > > > yes. as these applications typically live in separate packages anyway, > > > > there needn't to be an actual duplication if the alternatives are > > > > intelligently managed. for example, your wrapper could support a > > > > secondary source for executables, so if no lib32 version is found, the > > > > lib64 version is automatically used. > > > > > > Right, so not only are you not providing instructions, you're also asking > > > distributions to come up with new packaging rules for multiarch, requiring > > > features in their buildsystems that they don't have yet? > > > > one has to wonder how you arrive at these conclusions ... > > You're asking that they have a different 32-bit package to be installed on 64- > bit systems than then 32-bit package to be installed on 32-bit systems. > That's > a policy change. > last time i looked, /usr/lib/i386-linux-gnu was already different from /usr/lib/x86_64-linux-gnu, so "policy change" seems a bit far-fetched.
> > > > On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > > > > > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > > > > > arguments on why we should not manage that on "make install". > > > > > > > > because it's outside of -prefix? > > > > > > Clearly we should not touch anything outside -prefix. > > > > > > Which is why I'm proposing we recommend -prefix=/usr and then we *do* > > > manage that. > > > > this is a semantics game. the real prefix (the qt "sandbox" root) will be > > different anyway. just accept that the prefix of the wrapper is a > > different one, and consequently that it is a separate package. > > this wouldn't even change if the packagers use configure's path options > > in such ways that the "prefixes" actually end up intermingled. > > And I'm requesting that we stop this game of "qt sandbox root" and just do it > right, like every single other package: --prefix=/usr and manage our stuff > properly. > this doesn't quite fit the idea of the executable dispatcher. ;) the question is only whether we go the whole nine yards or stop halfway through. if we stop, the configure command line will be -prefix /usr -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of beauty. but then, -archlibdir needs adjustment anyway. > > > Do you hear yourself when you say that our make install is > > > insufficient? That distros need to move files around and create > > > symlinks on their own > > > > this sounds entirely reasonable to me. this is what packaging is about. > > Please talk to packagers then. "Reasonable" is "make install is sufficient". > yes. i've also seen packagers stop packaging KDE because we modularized the repositories. while i can understand a delay due to instantaneous workload, it is completely ridiculous to require upstreams to please the downstreams "just because". if you don't like a job, quit it. anyway, as the library renaming is apparently a decided thing, there is little point in hashing out the stupid arguments, given that this would merely produce an even equation which still calls for a decision. i just don't think you'll get as much out of this (as a whole) as you are hoping for. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
