Re: Source-Depends implementation
On Sun, Jan 10, 1999 at 11:33:52PM +0000, James Troup wrote:
> Ben Collins <bmc@visi.net> writes:
>
> > On Sun, Jan 10, 1999 at 07:25:37PM +0000, James Troup wrote:
> > > Ben Collins <bmc@visi.net> writes:
> > >
> > > > People have been asking for it, so here it is if any one wants to
> > > > write the policy for using it.
> > >
> > > Write policy around a `little hack' (your words)? Hmm.
> >
> > Not sure i what the size of the change has to do with it deserving
> > policy.
>
> It's not the size, it's the fact that you yourself describe it as a
> hack.
The term hack was used to mean that I didn't do a great deal of coding.
I don't consider a 2.5k diff much of a change so I wont call it
anything less than hacking. Your attack on that term in relation to
it's usefulness was very misguided. If you don't like my changes fine,
if you don't like my words, email private, as it has little to do with
what I was offering.
> > > > There is no versioning of the Source-Depends either since I didn't
> > > > think it would be necessary.
> > >
> > > You're wrong, they're very necessary.
> >
> > Examples please.
>
> e.g. libreadlineg2's make_quoted_replacement() was broken (causing
> segfaults in es and gdb) in << 2.1-4. If es or gdb merely depended on
> libreadlineg2, people would be free to compile binaries which
> segfaulted despite the source dependencies being satisfied. Proper
> constraints would avoid this.
Noted, I can add that in.
> > > > All it does is included the Source-Depends field into the .dsc
> > > > file. This can later be used by apt or dbuild/buildd to verify
> > > > that all needed packages are installed for building.
> > >
> > > sbuild already does this... (with it's own source dependencies
> > > generated from the dependencies of the binary package(s) of the
> > > source package and manually added source dependencies).
> >
> > This doesn't solve necessary binaries used in the make and build
> > process does it?
>
> Yes it does, as those are added by hand.
That does little more than what we do now...and not everyone who wants
this feature, wants to do manual adding, otherwise they wouldn't need
it any way.
> > And it doesn't help anyone else out...it's useless outside of that
> > one program.
>
> That `one program' compiles 98% of packages for m68k and powerpc with
> other architectures to come as soon as I get my act together and
> finish packaging it.
>
> I'm not claiming it's a perfect system, and I'm also surely not
> offering up bits of it as hacks for possible policy inclusion. You
> mentioned buildd, so I felt obliged to point out it was already doing
> something different, which worked better than your hack.
That's an impressive number, but it still has nothing to do with this.
It's like saying dselect does everything you could ever want...but not
everyone uses dselect. It needs to be in a better place, in the .dsc so
that any program can parse the output for usage. Mainly apt will find
it quite useful.
I also want to note that I don't think this should be required, most
source packages wont need it, just the ones that don't use the standard
things. IOW, don't make it policy, make it a documented feature.
--
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. bcollins@debian.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation
Reply to: