dpkg @1.14.29: update to 1.18.3

[cooljeanius (Eric Gallager)]

gl00b05046:opencflite-476.19.0 egall$ port livecheck dpkg
dpkg seems to have been updated (port version: 1.14.29, new version: 1.16.10)

[landonf (Landon Fuller)]

Not it! I'm not using dpkg/apt for anything anymore, so it's unlikely I'll have the time to port modern dpkg/apt versions. I just marked both ports as 'nomaintainer', anyone interested should feel free to pick them up.

[cooljeanius (Eric Gallager)]

OK well before I make any content changes here's a whitespace patch:

[cooljeanius (Eric Gallager)]

whitespace patch for dpkg

[cooljeanius (Eric Gallager)]

OK, working on the update, and some of the patches currently being used don't apply any more... removing them temporarily and attaching the rejects files here in the meantime if applicable.

[cooljeanius (Eric Gallager)]

failed patch for remove.c

[cooljeanius (Eric Gallager)]

failed patch for archives.c

[cooljeanius (Eric Gallager)]

failed patch for Makefile.in

[cooljeanius (Eric Gallager)]

failed patch for Makefile.am

[cooljeanius (Eric Gallager)]

failed patch for dselect/Makefile.in

[cooljeanius (Eric Gallager)]

failed patch for dselect/main.cc

[cooljeanius (Eric Gallager)]

failed patch for dselect/dselect.h

[cooljeanius (Eric Gallager)]

failed patch for start-stop-daemon.c

[cooljeanius (Eric Gallager)]

failed patch for help.c

[cooljeanius (Eric Gallager)]

OK, I have a portfile that passes port -v lint --nitpick and is able to successfully install dpkg at least, it ​fails port test and ​breaks the port dpkg command though... Attaching it anyways.

[cooljeanius (Eric Gallager)]

New portfile for dpkg

[cooljeanius (Eric Gallager)]

diff to apply to dpkg portfile after applying the whitespace patch

[afb@…]

I'm thinking that one should just delete the dpkg port and the "port dpkg" target altogether, but I haven't looked at the patches proposed above.

[cooljeanius (Eric Gallager)]

Replying to afb@…:

I'm thinking that one should just delete the dpkg port and the "port dpkg" target altogether, but I haven't looked at the patches proposed above.

dpkg-es are useful for portability though

[afb@…]

dpkg-es are useful for portability though

Already have .rpm, not sure what .deb would add (that isn't already covered by Fink and /sw/bin/dpkg) ?

Most likely nothing for MacPorts base, but it could fixed anyway for "other purposes" if there's interest.

Anyway, it needs to be patched to understand the "Darwin-x86_64" architecture and to use gnutar (not tar)...

And most of that should happen upstream.

[cooljeanius (Eric Gallager)]

Replying to afb@…:

dpkg-es are useful for portability though

Already have .rpm, not sure what .deb would add

rpms are only used by some distros, it wouldn't be as helpful for portability with distros that use debs

(that isn't already covered by Fink and /sw/bin/dpkg) ?

I thought we didn't support people having Fink installed at the same time? (I mean, I do that anyways, but I wouldn't expect others to...)

Most likely nothing for MacPorts base, but it could fixed anyway for "other purposes" if there's interest.

Well yeah, that's what I'm working on it for...

And most of that should happen upstream.

Yeah, that's what the Fink folks said, too...

[cooljeanius (Eric Gallager)]

Also speaking of Fink, they're having their own issues updating to dpkg 1.16: ​https://github.com/fink/fink/pull/66

[cooljeanius (Eric Gallager)]

After this we'll be able to update apt for #13425

[cooljeanius (Eric Gallager)]

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

[cooljeanius (Eric Gallager)]

OK, got most of the patchfiles to apply again (that weren't already integrated upstream at least) as best I could. The start-stop daemon still errors out though, so I'm leaving that disabled. Also port dpkg now works with this version.

[cooljeanius (Eric Gallager)]

port dpkg dpkg +docs

[cooljeanius (Eric Gallager)]

patch for configure.ac

[cooljeanius (Eric Gallager)]

patch for lib/dpkg/dpkg.h

[cooljeanius (Eric Gallager)]

patch for lib/dpkg/tarfn.c

[cooljeanius (Eric Gallager)]

patch for src/remove.c

[cooljeanius (Eric Gallager)]

patch for src/archives.c

[cooljeanius (Eric Gallager)]

patch for utils/start-stop-daemon.c

[cooljeanius (Eric Gallager)]

latest version of portfile for dpkg

[cooljeanius (Eric Gallager)]

Could this ticket be marked as "haspatch"? Also could landonf be added back onto cc? Even if he isn't the maintainer of dpkg anymore, I'd still appreciate his help with this ticket and the transferral of maintainership...

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Also could landonf be added back onto cc? Even if he isn't the maintainer of dpkg anymore, I'd still appreciate his help with this ticket and the transferral of maintainership...

Landon explicitly removed himself from this ticket. If you’d like him to get involved again, ask him directly.

[xeron (Ivan Larionov)]

Any status updates here?

[cooljeanius (Eric Gallager)]

Replying to xeron.oskom@…:

Any status updates here?

I have a newer version of the portfile at ​https://github.com/cooljeanius/LocalPorts/blob/master/sysutils/dpkg/Portfile, but I have avoided attaching it here because it includes a bunch of failed attempts at fixing #40807 (in the +docs variant) which are unnecessary...

[xeron (Ivan Larionov)]

Replying to egall@…:

I have a newer version of the portfile at ​https://github.com/cooljeanius/LocalPorts/blob/master/sysutils/dpkg/Portfile, but I have avoided attaching it here because it includes a bunch of failed attempts at fixing #40807 (in the +docs variant) which are unnecessary...

Could it be added w/o docs variant?

[xeron (Ivan Larionov)]

Cc Me!

[xeron (Ivan Larionov)]

So we are keeping old version just because +docs variant doesn't work or there are any other reasons?

I took your changes and have fixed them for 1.17.6, also I've added some changes to make "dpkg-source" working (it should use gnutar and gzip from ports). I can prepare a patch for current dpkg port if someone interested.

Code is here: ​https://github.com/xeron/xeron-macports/tree/master/sysutils/dpkg

[cooljeanius (Eric Gallager)]

Replying to xeron.oskom@…:

So we are keeping old version just because +docs variant doesn't work or there are any other reasons?

I took your changes and have fixed them for 1.17.6, also I've added some changes to make "dpkg-source" working (it should use gnutar and gzip from ports). I can prepare a patch for current dpkg port if someone interested.

Code is here: ​https://github.com/xeron/xeron-macports/tree/master/sysutils/dpkg

Mostly because I am not a committer yet and no one who is actually a committer seems interested enough... anyways I am attaching some new patches for the latest from the 1.16 branch... (I feel kind of unsure about using the odd-numbered branches like 1.17...)

[cooljeanius (Eric Gallager)]

my latest Portfile for dpkg

[cooljeanius (Eric Gallager)]

my latest diff to apply to dpkg portfile after applying the whitespace patch

[cooljeanius (Eric Gallager)]

diff between my current post-whitespace patch and my previous post-whitespace patch

[cooljeanius (Eric Gallager)]

Also having a po4a port would be useful: #41227

(not that I want to let that ticket hold up this one any more, but just saying, it could be useful...)

[xeron (Ivan Larionov)]

Oh completely forgot odd-numbered releases are unstable.

I've reverted it, applied you latest changes and my changes for dpkg-source. Also I've changed deps for perl to perl5.16 since depending on perl5 and p5-* libs makes a lot of mess like installing two different version of perl.

What do you think? We can ask in dev list to add this.

Attaching patch with all changes since current dpkg version.

[cooljeanius (Eric Gallager)]

Replying to xeron.oskom@…:

Also I've changed deps for perl to perl5.16 since depending on perl5 and p5-* libs makes a lot of mess like installing two different version of perl.

Unfortunately (at least last I checked) dpkg requires un-suffixed versions of the perl commands, and only the perl5 port installs them so far because the perl_select port does not work yet: #29763. This is the same reason that snc had to go and revert all the usage of a specific version of perl in ticket:29763:32.

[xeron (Ivan Larionov)]

Support of deb packages was removed in r123004, but I still want to see updated version of dpkg (I use dpkg-source for debian packaging). I've attached the latest version of patch (it uses perl portgroup now for dependencies resolving). WDYT? May be we could drop some patches because we don't need to support "port dpkg" now?

[cooljeanius (Eric Gallager)]

Replying to xeron.oskom@…:

Support of deb packages was removed in r123004, but I still want to see updated version of dpkg (I use dpkg-source for debian packaging). I've attached the latest version of patch (it uses perl portgroup now for dependencies resolving). WDYT? May be we could drop some patches because we don't need to support "port dpkg" now?

The change removing port dpkg from base hasn't been part of an official release yet, and I would kind of like to see it added back before 2.4 (the existence of the port dpkg command was one of the reasons I felt like working on this update in the first place, after all...)

However, if the change removing port dpkg does actually get released, I'm pretty sure the only part of my Portfile patch that would need to be changed would be that the line I added to the description (saying the port enables the use of the port dpkg command) would have to be removed. Other than that, pretty much everything else is unaffected by its removal, at least as far as I can tell...

Attachment dpkg_1.16.15.patch​ added

This is against the original Portfile currently in trunk, I take it? It's getting kind of hard to keep track of all of these patches; I think I had some other additional changes that I had been meaning to submit, as well... the longer this takes, the messier the merge could end up being...

[xeron (Ivan Larionov)]

Replying to egall@…:

This is against the original Portfile currently in trunk, I take it? It's getting kind of hard to keep track of all of these patches; I think I had some other additional changes that I had been meaning to submit, as well... the longer this takes, the messier the merge could end up being...

Yes it's against trunk. I believe it's better to have some progress here and (if it'll be required) support port dpkg later.

[xeron (Ivan Larionov)]

Since jessie has been released with 1.17.25 I don't think 1.17 is unstable anymore. Additional info from ​https://lists.debian.org/debian-devel-announce/2015/04/msg00007.html:

* Branches now named after the series versions.

  For downstream distributors it's not always easy to know which Debian
  release matches what dpkg series, so now the branches are named based
  on the series versions, backward compatibility refs have been created.

  The new names are 1.13.x (etch), 1.14.x (lenny), 1.15.x (squeeze),
  1.16.x (wheezy) and 1.17.x (jessie).

Attaching a patch for 1.17.25.

[xeron (Ivan Larionov)]

I just added patch which updates dpkg to 1.18.3.

It drops almost all old patches since most of this changes were implemented in upstream or extremely outdated.

This update was reviewed by dpkg developer Guillem Jover. If someone is interested you can read conversation here: ​https://github.com/xeron/xeron-macports/issues/1.

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

The commit needs to be done in two steps with the first one adjusting the spaces only. I'll adjust the spaces first (r142867).

[mojca (Mojca Miklavec)]

Is this expected?

checking sys/proc.h presence... yes
configure: WARNING: sys/proc.h: present but cannot be compiled
configure: WARNING: sys/proc.h:     check for missing prerequisite headers?
configure: WARNING: sys/proc.h: see the Autoconf documentation
configure: WARNING: sys/proc.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/proc.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------------- ##
configure: WARNING:     ## Report this to debian-dpkg@lists.debian.org ##
configure: WARNING:     ## ------------------------------------------- ##
checking for sys/proc.h... no

[mojca (Mojca Miklavec)]

I configured it with perl5.22, but it somehow manages to pick up Perl5.12 from somewhere. OTOH:

Warning: The following existing files were hidden from the build system by trace mode:
...
  /opt/local/lib/perl5/vendor_perl/5.22/darwin-thread-multi-2level/List/Util.pm
  /opt/local/lib/perl5/vendor_perl/5.22/darwin-thread-multi-2level/Scalar/Util.pm

[mojca (Mojca Miklavec)]

Mojca's suggestion of the Portfile (minor modifications wrt. Xeron's proposal)

[mojca (Mojca Miklavec)]

Perl 5.12 came from autoreconf, so it's a false alarm. I didn't try the functionality, but the port looks OK to me. I attached the Portfile with some very minor modifications compared to Xeron's upload. I removed some runtime and build dependencies because they are general dependencies already. Please let me know if I got some of those changes wrong (if I misunderstood the logic).

I added a line with an explicit Perl version and that seems to work except that p${perl5.major}-scalar-list-utils seems like an optional dependency (I leave it up to you to figure that out).

I commented out the elevated privileges. Given that the testsuite doesn't work 100% anyawy, it's safer to leave them uncommented for now. (I didn't try to understand why elevated privileges are needed.)

Just two questions left from my part:

• should xeron.oskom be a co-maintainer?
• Eric, given that you are the future (co-)maintainer, can you please confirm the changes?

Once the port is committed, I would suggest opening a ticket for the failed tests.

[xeron (Ivan Larionov)]

Thank you for review.

Replying to mojca@…:

Is this expected?

configure: WARNING: sys/proc.h: present but cannot be compiled

Expected. But we may report it to upstream.

In general I'm fine with your changes. Some notes:

• I don't like some places where you're doing things like this:

configure.env-append \
                    TAR=${prefix}/bin/gnutar

it looks strange when there's only one argument. But this is up to you, I'm not expert in TCL and macports guidelines.

• I'm not sure about specifying perl 5.22. It should be working with older versions as well.

• I don't understand where have you seen p${perl5.major}-scalar-list-utils, I don't see this dependency.

• We probably need to add lzma to build dependencies (we specify --with-liblzma for configuration) and xz to general or run dependencies.

[xeron (Ivan Larionov)]

Replying to mojca@…:

• should xeron.oskom be a co-maintainer?

You can add me as co-maintainer.

[mojca (Mojca Miklavec)]

Replying to xeron.oskom@…:

Thank you for review.

Replying to mojca@…:

Is this expected?

configure: WARNING: sys/proc.h: present but cannot be compiled

Expected. But we may report it to upstream.

Thanks.

In general I'm fine with your changes. Some notes:

• I don't like some places where you're doing things like this:

configure.env-append \
                    TAR=${prefix}/bin/gnutar

it looks strange when there's only one argument. But this is up to you, I'm not expert in TCL and macports guidelines.

This has nothing to do with TCL guidelines. There's a MacPorts consensus (also on the top of the file) which says that everything should be aligned to 4 spaces (if possible). The configure.env-append is just one character too long. Some developers add 4 extra spaces everywhere. Some break the lines. Some let it go for a few lines every now and then.

• I'm not sure about specifying perl 5.22. It should be working with older versions as well.

Yes, it should. But the port has to be bound to one fixed version. If you would install the port with Perl5.16 (let's say with perl5 +perl5.16) and if you then switch to Perl 5.22 and uninstall Perl 5.16, the port will no longer work unless you revbump it / reinstall it. You could give users the choice and provide variants. Which adds extra complications. See also #48365 (or #46570 whose main intention might no longer be desired). There's a lot of mess with these Perl ports and maybe we'll resolve that mess one day. Until then we need to make sure that ports are left in consistent state.

• I don't understand where have you seen p${perl5.major}-scalar-list-utils, I don't see this dependency.

I didn't look for this dependency, but if I try to install sudo port -v -t install dpkg and if you have scalar-list-utils installed (correspoding to the version of Perl that dpkg i using), then the trace mode complains that two of its files have been hidden. This means that installation scripts tried to access that module at some point.

• We probably need to add lzma to build dependencies (we specify --with-liblzma for configuration) and xz to general or run dependencies.

Maybe I need some further explanation here.

• Why would you need any other port than xz? xz-devel says "this port is only a stub and has been made obsolete by xz".
• If you add xz to depends_lib, there is no need for a separate depends_build and depends_run. Either you only provide depends_build and/or depends_run (provided that there is no linking involved) or you provide just dependes_lib which implies both other dependency types.
• I admit that I don't understand the exact difference between lzma and xz. Which port provides whatever --with-liblzma needs? xz or lzma? Does the binary link against lzma/xz?
• I see

  lzma seems to have been updated (port version: 4.65, new version: 15.12)
  

[xeron (Ivan Larionov)]

Looks like scalar-list-utils is a part of perl core since perl 5.20. So we don't need this dependency.

And about lzma/xz — I was confused by debian dependency on liblzma-dev for build and xz-utils for runtime and thought we need both. But for example homebrew version of dpkg formula only depends on xz. Also it provides liblzma as well. So we need only xz dependency.

[mojca (Mojca Miklavec)]

I committed r142883. I somehow suspect that gnutar could be a build+runtime dependency only, but maybe I am wrong. zlib, xz, bzip2 are all linked against, so there is no need to specify them also as build or runtime dependency.

[xeron (Ivan Larionov)]

Awesome! Thank you for helping.

[xeron (Ivan Larionov)]

Also it probably closes #14559.

[mojca (Mojca Miklavec)]

There is also #32055. Unless someone knows what to do with it, I would close it.

[RJVB (René Bertin)]

OLD ticket, I know ... does anyone remember why this port has extract.asroot yes? I notice that I can run apt-get source dpkg on Ubuntu just fine as myself, and then build the package without issue ... and even the MacPorts $worksrcpath tree is owned by macportsuser after extracting as root.

[xeron (Ivan Larionov)]

I don't remember. I think I wasn't the one who added it. I tested and build works just fine without it. I can open a PR to remove extract.asroot yes but I won't be able to explain why it was added.

[cooljeanius (Eric Gallager)]

Replying to xeron:

I don't remember. I think I wasn't the one who added it. I tested and build works just fine without it. I can open a PR to remove extract.asroot yes but I won't be able to explain why it was added.

I think I was probably the one who added it, but I can't remember why I did so. If it works fine without it, then feel free to remove it.

Edit: ah wait I think I found the commit in my local Portfile repo where I added it, but unfortunately my past self didn't leave a very informative commit message, so I forget what exactly the "permissions thing" in question was: ​https://github.com/cooljeanius/LocalPorts/commit/72b7ad133a5e468663c8fa7e2aae7589a45a0820