Re: Challenge to you: Voice your concerns regarding systemd upstream

[Miles Fidelman <mfidelman@meetinghouse.net>]

Reco wrote:
>   Hi.
>
> On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 09/29/2014 at 05:49 AM, Reco wrote:
> >
> > > Hi.
> > >
> > > On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote:
> > >
> > > > Debian already lost me (after over 15 years) when they came up
> > > > with their brokenarch and left users stranded with no possible
> > > > fix for the things they broke.  The only reason I'm here is
> > > > because I have it running on my server, and the only reason I
> > > > have it on my server is because it was the only distribution of
> > > > those I tried with which I could get xen to work.  I really
> > > > didn't want to use Debian.
> > > What's wrong with the current multiarch implementation in your
> > > option? I'm really curious as all multiarch complains I've seen so
> > > far (barring actual package limits) were easily solved just by
> > > reading an appropriate man page (or Debian wiki page).
> > >
> > > And, IMO, Debian's current multiarch is way more flexible than
> > > current Fedora's one.
> > I don't know about him, but although I'm a big supporter of multiarch in
> > general, I do know of one major thing which broke with the transition
> > from the old arrangement: x86 builds on amd64 hosts.
> >
> > Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and
> > ia32-libs-dev provided the matching header files. (Separate lib*32
> > packages provided other libraries, and matching -dev packages provided
> > the matching header files for those other libraries.) With both of those
> > together, and compiler options like 'gcc -m32', it was possible to
> > compile code against 32-bit libraries in a 64-bit environment and then
> > run the result in that same environment.
> >
> > Under multiarch, lib*:i386 packages provide the x86 libraries, and there
> > is nothing which provides the matching header files. That sort of
> > compilation task is no longer possible, at least not in a remotely
> > trivial or automated fashion.
> Header files are arch-agnostic, it's the .la files that case all the
> trouble. Still, you're raising a valid point - compiling for several
> arches was possible before multiarch, and it's not possible now without
> chroots. I prefer chroots for this (less strange dependencies in the
> 'base' system), but YMMV.
>
> About the only thing that I'm missing here is why would anyone should
> compile anything on a production server, Xen's dom0 specifically (as it
> seems to be the main lee's concern).

I do it all the time.  Packaging of some of the things we run on our 
list and web servers tends to run behind upstream, sometimes by quite a 
bit.
"./configure; make install" is pretty much as easy as apt-get install

As a general rule, I find that I use packaged software for all of our 
base capabilities (utilities, dns, time, and so forth), and build from 
upstream source for the production systems.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra