Christian Leutloff <[EMAIL PROTECTED]> writes:
> 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 think you may still be missing the point. If you use Ian's
approach, and then someone downloads
foo_1.0-1.diff.gz
foo_1.0-1.dsc
foo_1.0.orig.tar.gz
then when they build the package they should get a nearly identical
(if not completely identical) set of binary packages to the ones
residing on the ftp sites.
If you use the debmake/debhelper approach, then you may get something
*very* different, depending on the version of debmake/debhelper
installed. This makes tracking down packaging problems reported by
others unnecessarily difficult, with no real benefit.
User: Building your package doesn't work right.
Developer: Works fine for me.
User: But I used the source packages you gave me? Isn't that supposed
to be sufficient?
[...time elapses...]
Developer: Oh, wait. What version of debhelper/debmake do you have
installed?
User: That matters?
Now granted, source dependencies could fix some of the problem, but
usually we only include version specific dependencies in unusual
cases. The nature of debmake/debhelper would essentially mandate that
every package built with them include a specific version dependency to
guarantee reproducable builds. That's pretty ugly IMO.
All that said, I understand the vaporware argument. I'm not talking
about whether or not we should continue to maintain debmake/debhelper,
but about where future development resources should be allocated.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
