On Aug 28, 2020, at 10:31 PM, Daniel Macks <dma...@netspace.org> wrote:
(continuing with top-posting pattern of this thread...) If we don't do la cleanup when
installing old deb, then there will be bits present in the installed la that will either
easily break building other packages or lead to propagated binary differences in them.
The cleanup removes bits that trigger additional (but needless) -lfoo
flags...uncontrolled inherited BDep. The current cleanup method definitely breaks
md5sums, but was the only way to get consistent and non-weirdly-breaking end-user
experience that we could find ("least crappy solution that was actually doable
without a time machine"). Clearing those bits when creating the .deb is the perfect
solution, but we'd have to disallow uncleared .deb if we don't do the clearing in
PostInst. Maybe if we're making such a hard break we should actually do that?
dan
On 8/28/20, 3:24 PM, "Justin Hallett" <the...@southofheaven.org> wrote:
It will work, new debs won’t work with old dpkg but there is a dpkg
pre-depends injected into them
The difference is triggers, and some of the la processing. Current fink
breaks debsums (and Debian rules) as it changes the la files after install,
this changes the md5sum and thus breaks debsums to check for changed files.
The new dpkg deals with it before, and uses triggers from the fink packages
to do other than that used to be injected into postinst script.
Older dpkg will just ignore fields is doesn’t know like pre-depends and
triggers. But a deb built with the dplg1.16 branch and the someone built with
master won’t be the same deb which breaks fink policy. Most of the changes and
differences are all in the la files and the Debian control directory. So the
binaries and libs will be the same.
In summary there is no danger I made sure of it. But fink policy needs to
be amended if we want to allow upgrades.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
On Aug 28, 2020, at 1:17 PM, f...@snaggledworks.com wrote:
Will old debs work with the new dpkg? Or is the deb compatibility broken in
both directions?
If we're going to need a new tree (called "11.0"?), what distributions
should we put into it? Obviously macOS 11.0. Should we also put 10.14.5 and 10.15 into
it? These two share the same /usr/bin/perl (v5.18.4), but it's different from 11.0
(v5.28.2). However, 11.0 has /usr/bin/perl5.18(.4) as well. Is it worth (possible?) going
down to earlier system versions? 10.10-10.14 share the same system-perl (5.18.2)
Hanspeter
On 2020-08-28 11:13, Justin Hallett wrote:
I’m almost positive all the packages are compare (texinfo might have
an extra split) but you can not put dpkg into the 10.5 tree since
it’ll break deb compat. This branch needs a new tree then it can be
added.
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
On Aug 28, 2020, at 9:59 AM, Alexander Hansen
<alexanderk.han...@gmail.com> wrote:
On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser
<f...@snaggledworks.com> wrote:
What's the upgrade process for the dpkg1.16 branch and the dists
tree?
Several packages are now essential (e.g. time-date-pm and xz) and
will have to be moved from their present subfolders in dists to
'base'. Also, some base packages have newer versions than what's
in the dpkg1.16 branch source (e.g. libiconv and texinfo). But the
dpkg1.16 branch versions have needed changes that might be
incompatible with older fink installs, so we can't just copy
what's currently in dist to the dpkg1.16 branch, or push the
dpkg1.16 branch versions directly into dists. Or are dpkg1.16
packages compatible with legacy dpkg?
Hanspeter
At minimum, the most logical thing to do would be to update
libiconv, texinfo, et. al. in the dpkg1.16 branch and also apply the
branch-specific changes - i.e. merge them in a logical sense if not
in a Git sense. I hate to say it, but this might be a case for a
new distro and clean reinstall rather than update in place. I know
we just did that for Catalina, but my impression is that Big Sur is
going to change a bunch of stuff.
--
Alexander Hansen, Ph.D.
Fink User Liaison
