[1896] in athena10
Re: Athena delete
daemon@ATHENA.MIT.EDU (Tim Abbott)
Thu Mar 26 15:36:08 2009
Date: Thu, 26 Mar 2009 15:35:19 -0400 (EDT)
From: Tim Abbott <tabbott@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: Anders Kaseorg <andersk@mit.edu>, debathena@mit.edu
In-Reply-To: <29FD6D41-E68F-4170-B174-5E9F1D5C7CCC@mit.edu>
Message-ID: <alpine.DEB.1.10.0903251808270.30486@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1257098496-1050793950-1238018916=:30486"
Content-ID: <alpine.DEB.1.10.0903261534400.7289@vinegar-pot.mit.edu>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1257098496-1050793950-1238018916=:30486
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.DEB.1.10.0903261534401.7289@vinegar-pot.mit.edu>
It sounds like we don't want to merge the spec file.
But presumably we do want to merge the various bug fixes. We should=20
probably get back to jik about this.
=09-Tim Abbott
On Sun, 22 Mar 2009, Jonathan Reed wrote:
>=20
> On Mar 22, 2009, at 2:06 AM, Anders Kaseorg wrote:
>=20
> > I=A2m not sure who jik is, and I don=A2t really like the tone of his re=
quest
> > that we add an RPM specfile to our source tree (plus I=A2m already not =
so
> > happy that we added debian directories there; software _should_ be
> > separable from its packaging), but his patches might be worth looking
> > at.
>=20
>=20
> As Kevin pointed out, jik wrote delete, so I think it's reasonable for us=
to
> take patches from the original author of the package.
>=20
> Addressing the general case, I'm not sure how the presence of a debian
> directory or spec file implies that the software is not separable from it=
s
> packaging. I can think of several packages that ship with spec files and=
/or
> debian directories for easy packaging. The software will build just fine=
with
> out them, you just can't type "make rpm" unless you're on Redhat, or "mak=
e
> dpkg" unless you're on Debian. For example, the upstream source for lpr=
ng
> (lprng-3.8.28dfsg.1 on my stock Hardy machine) includes a DISTRIBUTIONS
> subdirectory, containing the metadata necessary to build an RPM, a
> Solaris.pkg, and a FreeBSD port. If you don't wany any of those things, =
you
> simply don't CD into that directory - nothing in the main source tree dep=
ends
> on it.
>=20
> I can see a downside, in that if we provide a spec file, perhaps we're
> obligated to maintain and test it, which we may not want to be in the bus=
iness
> of doing. On the other hand, I think it's inevitable that Debathena will
> eventually make its way to other platforms or distributions (Fedora and O=
S X
> come to mind), so perhaps we want to address this issue now. If the debi=
an
> directories were not in the source tree, where would they be and what wou=
ld
> the build process look like? If they live elsewhere, could RPM spec fil=
es
> and, say, OS X package metadata live there too?
>=20
> -Jon
---1257098496-1050793950-1238018916=:30486--
