Christian Leutloff wrote: > > I don't believe that debhelper address one of Ian's main complaints at > > all. If I remeber correctly, that complaint was that when you use > > debmake (or debhelper), you end up with debian package source with > > non-deterministic behavior. Depending on the version of the packaging > > tool installed on the system you use to build the package, you may get > > a radically different resulting set of binaries. > > But using another compiler or dpkg would result in a different set of > binaries, too. To get rid of the problems we need source depends.
With debmake, new functionality was added all the time, and was added into the same debstd program, changing its behavior, and so different versions could have widly differing results on the same package. With debstd, each individual program has a well-defined job, and so their behavior will not change, execpt for bugfixes, and to comply with changes in debian policy. New functionality comes in the form of added programs, so your debian/rules that uses debhelper will behave the same no matter what version of debhelper you use. > it's nice to have, but brings no advantages. If we change the > autoconfish thing we get the same different binaries as through > changing debhelper/debmake. It's IMHO only a different view but no > substantial change. And debhelper is working NOW - the other approach > is vaporware. I'd be interested to see the autoconf-style thing implemented. I'm not sure yet if I'd use it; it's very hard to decide when it is, indeed, vaporware. -- see shy jo
pgpzX7k8ve7KM.pgp
Description: PGP signature
