Re: Summary? Re: source dependencies - and recomndations
- To: email@example.com
- Subject: Re: Summary? Re: source dependencies - and recomndations
- From: Steve Greenland <stevegr@NeoSoft.COM>
- Date: Fri, 1 Aug 1997 14:33:28 -0500
- Message-id: <19970801143328.54208@NeoSoft.COM>
- Reply-to: stevegr@NeoSoft.COM
- In-reply-to: <199707312222.AAA01438@bylbo.nowhere.earth>; from Yann Dirson on 01/08/97
- References: <19970729224747.25931@kite> <Pine.LNX.3.96.970730105741.7292A-100000@S002> <19970730022907.16396@kite> <firstname.lastname@example.org> <19970730124015.20235@kite> <199707302040.WAA01146@bylbo.nowhere.earth> <19970730222902.13437@NeoSoft.COM> <199707312222.AAA01438@bylbo.nowhere.earth>
On Aug 1, Yann Dirson <email@example.com> wrote:
> Steve Greenland writes:
> > I don't like Case 2, mostly because I disagree that we ought to be
> > solving that goal. If you want (re-)build the debian package, then it's
> > not sufficient, if you don't, you're probably working with the original
> > source anyway.
> I don't agree with this last sentence: using a debianized source is
> the best way to handle upgrades/uninstalls on a Debian machine. I
> think case 2 could be useful.
But then you'd want to build it like the maintainer, right? So that's
a case 1.
Think about this: Package A depends on B, because it requires
some functionality in B. User re-builds B, but only meets the
"Source-Depends", not the "Source-Suggests", so B is built with
non-Debian-standard functionality. When you install A, it installs OK,
because B is there, and the binary dependency is met, but then A fails
mysteriously because of B's missing functionality.
The Mole - I think, therefore I scream
"Shulang it! This is exactly the treatment we've
come to expect from Delta Airlines!"
[BADGER in NEXUS]
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .