(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 _______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core _______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core _______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core _______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core