[MacPorts] #39018: dpkg @1.14.29: update to 1.16.10
MacPorts
noreply at macports.org
Wed May 15 09:00:42 PDT 2013
#39018: dpkg @1.14.29: update to 1.16.10
----------------------+---------------------
Reporter: egall@… | Owner: egall@…
Type: update | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: dpkg |
----------------------+---------------------
Comment (by egall@…):
Copying and pasting the relevant parts of an irc conversation I had with
landonf about some of these patches, for easier reference:
{{{
[17:53:43] <egallager> oh hi landonf
[17:53:51] <landonf> hulloooooo!
[17:54:11] <egallager> hey so I've been working on updating the dpkg port
since you gave it up...
[17:54:45] <egallager> can you explain what all the patchfiles were for,
and if they're even needed anymore? None of them apply to the latest
version...
[17:56:03] <landonf> let me just turn my brain back 5-8 or so years ...
[17:56:18] <egallager> lol
[17:57:08] <landonf> longer than that, wow.
[17:57:13] <landonf> 9-10!
[17:57:24] <egallager> wow
[17:57:33] <landonf> All the commit messages should be fairly descriptive
on the patches
[17:57:41] <landonf> The short version is that they were all for
portability
[17:58:17] <landonf> take patch-main_remove.c for instance
[17:59:18] <landonf>
http://trac.macports.org/browser/trunk/dports/sysutils/dpkg/files/patch-
main_remove.c#L8
[17:59:58] <egallager> ok, just found my copy in my local portfile repo...
[18:00:26] <landonf> In that case, the comment is descriptive, but it
should be possible to determine from code comments + log messages what the
intent was
[18:01:53] <landonf> For patch-main_remove.c, the thing to test is whether
deleting the last package on the system explodes in the current version of
dpkg
[18:02:11] <landonf> It did back then, and the inclusion of '/.' in the
packaging list was the cause
[18:02:32] <egallager> well I've tried running the test suite, but it
fails when not run as root...
[18:03:01] <landonf> I wouldn
[18:03:07] <landonf> wouldn't trust debian's test suite
[18:03:23] <egallager> that's what they said in #fink too
[18:03:32] <landonf> That failure case, for instance, is something that
-never- happens on Debian because dpkg itself is a package.
[18:03:50] <egallager> right
[18:05:52] <egallager> how do you read the rejects files left over from
failed patches?
[18:05:58] *** Dessimat0r has joined #macports
[18:06:49] <egallager> Are they basically just patches themselves, except
only made up of the leftovers that didn't apply?
[18:07:05] <landonf> lessee. patch-lib_tarfn.c adds support for dpkgs
built with the ustar format, which fixes long filename handling when not
using gnutar. It also fixes a bug in dpkg's stripping of '/' characters
when there weren't any (also probably related to bsdtar, but I don't
remember the exact failure case).
[18:07:10] <landonf> egallager: yep, exactly that.
[18:08:19] <egallager> ok so it looks like with the "remove" patch, the
first part applied, but not the second part...
[18:09:07] <egallager> let's see, would it be better to edit the patches
directly, or to try to regenerate them?
[18:09:34] <landonf> patch-main_archives.c also adds support for handling
format differences between bsdtar and gnutar related to pathname prefixes
[18:10:16] <landonf> And patch-utils_start-stop-daemon.c is probably the
most complicated, in that it adds Mac OS X support to the various process
handling functions debian uses to start/stop/monitor daemons. I think
that's all the tricky patches ....
[18:10:24] <landonf> egallager: regenerate them. rewrite them, even.
[18:10:39] <egallager> I just turned off the start-stop daemon thing with
a configure flag...
[18:10:41] <landonf> They're almost certainly not going to apply cleanly,
or even necessarily still be needed at all.
[18:11:47] <egallager> is the start-stop daemon even needed? Just want to
know if turning it off like that is ok...
[18:13:00] <landonf> It's considered part of dpkg, but macports ships its
own 'daemondo' that serves as an alternative
[18:13:26] <landonf> So it's not strictly necessary, but it is useful.
[18:14:42] <egallager> so turning it off with a configure flag is ok then?
[18:15:21] <landonf> If the alternative is not having dpkg at all,
absolutely :D
[18:15:37] <landonf> It's a nice-to-have, but afaik not necessary to have
a working dpkg.
[18:16:35] <egallager> yeah, I mean Homebrew turns off the installing
capabilities of dpkg entirely, so I'd say that the start-stop daemon is
relatively a much smaller thing to give up
}}}
Also instead of attaching another version of the portfile, I'll just link
to my WIP version on GitHub until I'm satisfied enough with it to submit
it for real:
https://github.com/cooljeanius/LocalPorts/blob/master/sysutils/dpkg/Portfile
--
Ticket URL: <https://trac.macports.org/ticket/39018#comment:13>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list