Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <1321975561.50412.YahooMailClassic@web113516.mail.gq1.yahoo.com>
Date: Tue, 22 Nov 2011 07:26:01 -0800 (PST)
From: Pedro Giffuni <pfg@apache.org>
Reply-To: pfg@apache.org
Subject: Re: [CODE]: 118605 remove epm?
To: ooo-dev@incubator.apache.org
Cc: =?iso-8859-1?Q?J=FCrgen_Schmidt?= <jogischmidt@googlemail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="-1840540646-503637379-1321975561=:50412"

---1840540646-503637379-1321975561=:50412
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Well ...=0A=0AWe need something that works now and basically something=0Ath=
at will produce RPMs. Having something to do this is handy=0Abut should not=
 a requirement for building. I think with just=0Ahaving it disabled by defa=
ult we comply with the ASF policies.=0A=0AAll other packages that I know of=
 just have an installation=0Ascript and leave the packaging for someone els=
e to do: for=0AFreeBSD we use a script that calls tar (it's more portable=
=0Athan cp), and then we have some support in the ports tree=0Ato package t=
hat stuff automatically.  =0A=0AHmm... since you are apparently planning to=
 further edit=0Afetch_tarballs.sh, perhaps you can test my update to that=
=0Ascript? (attached).=0A=0Acheers,=0A=0APedro.=0A=0A=0A--- On Tue, 11/22/1=
1, J=FCrgen Schmidt <jogischmidt@googlemail.com> wrote:=0A=0A> Hi Pedro,=0A=
> =0A> On 11/22/11 1:52 PM, Pedro Giffuni wrote:=0A> >=0A> > Hmmm ...=0A> >=
=0A> > Nevermind, OpenPKG is rather bulky.=0A> > Unfortunately portable pac=
kagers seem not=0A> > to be too common anymore.=0A> =0A> the point is simpl=
y that we have to understand the whole=0A> packaging =0A> process better. I=
 thought it was worse to check if it's=0A> possible to use =0A> a system ep=
m. Sometimes things become easier over time or=0A> even obsolete. =0A> But =
in this case it seems that we have to stick with the=0A> 3.7 epm and the =
=0A> patches we have because they are very specific for OOo.=0A> =0A> I hop=
e that we can simplify this packaging process in the=0A> future a =0A> litt=
le bit because we can concentrate on one product only.=0A> In the past =0A>=
 all processes here were designed to make it possible to=0A> build a =0A> S=
tarOffice/Oracle Office version on top of it.=0A> =0A> The problem is that =
we have to analyze the whole process to=0A> understand =0A> how it works. I=
n the past one developer worked full-time on=0A> this =0A> packaging stuff =
...=0A> =0A> Juergen=0A> 
---1840540646-503637379-1321975561=:50412--