2006/6/27, Éric Bischoff <[EMAIL PROTECTED]>:
Le Mardi 27 Juin 2006 10:10, Janne Johansson a écrit:
> > Any package maintainer listening here to confirm or denegate what I am
> > saying ? I used to work in a linux distribution, so I think I can
express
> > opinions on this topic, but some package maintainers might see that
> > differently.
>
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is
> meant to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.
>
> If not for those reasons, then for the reason that zillions of other
> opensource products happen
> to have a "unpack ; configure ; make ; make install" routine well built
in
> into the spines of us builders.
For which distro are you facing those problems?
We have a multiplatform packaging system (though I dont expect OOo2 to
build for anything else than linux-x86) called "buildit" which is a
collection
of shellscripts that automate the above procedure (unpack, conf...) and does
some dependency handling. It's very small, internal for us, but seems to
work
for the majority of normal apps that obey configure
--prefix=/somewhere/else.
Also, we are running our linuces on a small system for which we dont pull in
any
(except X11) dist-apps, but rather keep our own apps in versioned
directories
(like /pkg/tcsh/6.14.00/bin/tcsh) so we can keep parallell instances next to
each
other. This may or may not be the silliest idea since sliced bread but it
does
make it very visible which projects are relocatable "easily" and which want
everything
under /usr/{bin/lib/share}. OOo2 strikes me as a "you should have stuffed it
all
in one place because it breaks otherwise" when working on it.
There are so many points where the "unstandard" build style of OOo hits me.
Our build system naievely assumes "unpack ; patch ; prep (configure) ; build
; install"
works, but since OOo2 does unpack stuff after configure is run and don't
seem to
propagate configure-stuff to the newly unpacked configures, I seem to loose
out
on stuff. (libxmlsec gets a --without-openssl even though I gave the
toplevel an openssl
argument; pyuno gets a PYTHON_CFLAGS with -I/my/path/include but not a
PYTHON_LIBS with -L/my/path/lib)
And to actually get somewhere back to the original Q about the "dev" (or in
my case builder)
experience, I feel like it does copy lots of gifs and does zip magic on
dpzz's lots and lots
early on, making the turnaround times for figuring out which flags dont work
take a long while.
For me.
I've also found out "dmake -P3" makes it go "sleep 1" in a lot of subdirs
between builds.
--
Some mornings, it's just not worth gnawing through the straps...
