Re: Darwin Patches (was: Replaces and virtual packages)
On Tue, 23 Oct 2001, Christoph Pfisterer wrote:
> This whole FIX_PERCENT_ZI thing is there because Darwin's libc
> doesn't support %zi in *printf and *scanf. The macro and the
> associated function was the only fix I could come up with that:
>
> 1) Fixes the problem on Darwin
> 2) Doesn't add run-time overhead on other platforms
> 3) Doesn't break i18n
>
> I guess 3) is why I didn't use the macro on the sscanf, which of
> course is not a good idea for other platforms.
I guess. Still seems ugly. I'd rather have local copies of printf and scanf
in that case, that get linked in after configure detects broken versions in
libc(we do that for optlib/obstacks.c, for instance).
> I actually posted this to the list some weeks ago and got no reply.
> Darwin does have symlinks, but it doesn't have lchown() and instead
> uses the owner of the containing directory when asked for the info.
> Using chown() instead is bad because it changes ownership of the link
> _target_. That is not only not the intended behaviour, but also leads
> to errors when the target doesn't exist. dpkg-deb tries to sort links
> to the back of the file list, but unfortunately there are packages
> which contain links to links, which can trigger errors. I first
> encountered that with gtk's gtkrc files.
Never saw it. I'd like a configure option.
I have a patch that actually reorders symlink at package install time, instead
of package build time. Also(and this hasn't been done yet), I want to make
the targets of symlinks come before the symlinks themselves. This is
non-trivial(however, I haven't tried).
> Job control is there alright, but for some unknown reason getpgid()
> isn't. :-( I was too lazy to add a proper autoconf test, sorry.
Again, a configure test would be wanted for this, before I felt like applying
to cvs.
> >No ldconfig on darwin?
>
> No, it's not necessary because the full path of libraries gets
> encoded into the executables (and into the libraries for that
> matter). Basically like -soname, but with the full path.
Ew! So, how does LD_PRELOAD or LD_LIBRARY_PATH work, if the full path is
encoded into the binary? This is the same breakage as libtool and rpath.
Additionally, package installation scripts call ldconfig, and I highly doubt
you should be modifying them to not call it. It'd be better to dpkg-divert
ldconf to /bin/true(or otherwise link it).
> >I don't see ADMINPREFIX defined. What is this supposed to do?
>
> It's replaced with sed before the patch is applied. The rest of dpkg
> adheres to the prefix set through the configure script...
Well, this change can't be accepted as is. This file doesn't get changed on
non-darwin installs by your scripts. If you were to change it to do so, I'd
be more willing.
> There's also one more chunk which you probably missed because it's
> still in Fink's unstable section:
bash-2.05$ grep processarc build/t/fink-0.3.0-full/pkginfo/dists/unstable/main/finkinfo/base/dpkg-1.9.17-1.patch
bash-2.05$
> diff -ruN dpkg-1.9.17/main/processarc.c dpkg-1.9.17-patched/main/processarc.c
> --- dpkg-1.9.17/main/processarc.c Mon Apr 23 22:42:17 2001
> +++ dpkg-1.9.17-patched/main/processarc.c Fri Oct 19 11:34:10 2001
> @@ -196,8 +196,8 @@
> pkg->files= nfmalloc(sizeof(struct filedetails));
> pkg->files->next= 0;
> pkg->files->name= pkg->files->msdosname= pkg->files->md5sum= 0;
> - pkg->files->size= nfmalloc(30);
> }
> + pkg->files->size= nfmalloc(30);
> sprintf(pkg->files->size,"%lu",(unsigned long)stab.st_size);
>
> if (cipaction->arg == act_avail) {
>
> This fixes a segfault that occurs when a package with the same
> version is reinstalled that has changed sufficiently to increase the
> length of the Size field. When a package is already present,
> pkg->files->size already exists and is reused, but it's only
> allocated to fit. Some more analysis by Matthias Neeracher (who
> tracked this down) is in this SourceForge bug report:
> <http://sourceforge.net/tracker/index.php?func=detail&aid=467762&group_id=17203&atid=117203>
http://bugs.debian.org/115720
It also has a slightly more appropriate explanation.
> (Yes, I know it's BAD to change a package without incrementing the
> revision number. But it's useful while developing a package, and
> actually only packagers have been hit by this bug, while adjusting
> their own packages.)
It has nothing to do with changing the package during development. This can
happen to normal users(as the above bug report shows).
There will be a .18 upload of dpkg to debian unstable this week for this bug.
Reply to: