[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