[Development] Pending decisions on co-installation

Oswald Buddenhagen oswald.buddenhagen at digia.com
Thu Nov 1 20:32:06 CET 2012


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.



More information about the Development mailing list