Re: upgrade process for big sur/dpkg1.16
Justin Hallett <[email protected]> Sat, 29 Aug 2020 10:16:02 -0600
| Newsgroups | gmane.os.apple.fink.core |
|---|---|
| Message-ID | <[email protected]> |
--===============6179540617720238727== Content-Type: multipart/alternative; boundary="Apple-Mail=_8C5A79BF-5AFA-47B6-88A3-570A7EC81020" --Apple-Mail=_8C5A79BF-5AFA-47B6-88A3-570A7EC81020 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The old debs will still work the same way as it=E2=80=99s part of the = postinstscript. Just the content in the deb of the la files will differ the end result = will be the same. --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! > On Aug 28, 2020, at 10:31 PM, Daniel Macks <[email protected]> = wrote: >=20 > (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? >=20 > dan >=20 >=20 >=20 > On 8/28/20, 3:24 PM, "Justin Hallett" <[email protected]> = wrote: >=20 > It will work, new debs won=E2=80=99t 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. >=20 > 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. >=20 > Older dpkg will just ignore fields is doesn=E2=80=99t know like = pre-depends and triggers. But a deb built with the dplg1.16 branch and = the someone built with master won=E2=80=99t 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. >=20 > 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/ >=20 > Life begins and ends with chaos, live between the chaos! >=20 >=20 >=20 >=20 > On Aug 28, 2020, at 1:17 PM, [email protected] wrote: >=20 > Will old debs work with the new dpkg? Or is the deb compatibility = broken in both directions? >=20 > 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) >=20 > Hanspeter >=20 > On 2020-08-28 11:13, Justin Hallett wrote: >=20 > I=E2=80=99m 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=E2=80=99ll 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 > <[email protected]> wrote: > On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser > <[email protected]> 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 >=20 >=20 > 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 > [email protected] > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core >=20 >=20 > _______________________________________________ > fink-core mailing list > [email protected] > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > fink-core mailing list > [email protected] > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core >=20 >=20 >=20 >=20 > _______________________________________________ > fink-core mailing list > [email protected] > List archive: > http://news.gmane.org/gmane.os.apple.fink.core > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-core --Apple-Mail=_8C5A79BF-5AFA-47B6-88A3-570A7EC81020 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">The = old debs will still work the same way as it=E2=80=99s part of the = postinstscript.<div class=3D""><br class=3D""></div><div class=3D"">Just = the content in the deb of the la files will differ the end result will = be the same.<br class=3D""><div class=3D""> <span class=3D"Apple-style-span" style=3D"border-collapse: separate; = color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; " class=3D""><p style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal = normal normal 12px/normal Helvetica; " class=3D"">---</p><p = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; font: normal normal normal 12px/normal Helvetica; " = class=3D"">TS</p><p style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; font: normal normal normal = 12px/normal Helvetica; " class=3D""><a = href=3D"http://www.southofheaven.org/" = class=3D"">http://www.southofheaven.org/</a></p><p style=3D"margin-top: = 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: = normal normal normal 12px/normal Helvetica; " class=3D""><font = class=3D"Apple-style-span" color=3D"#0000EE"><span = class=3D"Apple-style-span" style=3D"text-decoration: underline; = "></span></font></p><p style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; font: normal normal normal = 12px/normal Helvetica; " class=3D"">Life begins and ends with chaos, = live between the chaos!</p> </div> </span></div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div= class=3D"">On Aug 28, 2020, at 10:31 PM, Daniel Macks <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">(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?<br class=3D""><br class=3D"">dan<br class=3D""><br class=3D""><br = class=3D""><br class=3D"">On 8/28/20, 3:24 PM, "Justin Hallett" <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br class=3D""><br = class=3D""> It will work, new debs won=E2=80=99t work = with old dpkg but there is a dpkg pre-depends injected into them<br = class=3D""> 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.<br class=3D""><br = class=3D""> 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.<br class=3D""><br class=3D""> = Older dpkg will just ignore fields is doesn=E2=80=99t = know like pre-depends and triggers. But a deb built with the = dplg1.16 branch and the someone built with master won=E2=80=99t 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.<br class=3D""><br = class=3D""> In summary there is no danger I made sure = of it. But fink policy needs to be amended if we want to allow = upgrades.<br class=3D""> ---<br class=3D""> = TS<br class=3D""> <a = href=3D"http://www.southofheaven.org/" = class=3D"">http://www.southofheaven.org/</a><br class=3D""><br class=3D"">= Life begins and ends with chaos, live between the = chaos!<br class=3D""><br class=3D""><br class=3D""><br class=3D""><br = class=3D""> On Aug 28, 2020, at 1:17 PM, <a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a> wrote:<br class=3D""><br class=3D"">= Will old debs work with the new dpkg? Or is the deb = compatibility broken in both directions?<br class=3D""><br class=3D""> = 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)<br class=3D""><br class=3D""> = Hanspeter<br class=3D""><br class=3D""> = On 2020-08-28 11:13, Justin Hallett wrote:<br = class=3D""><br class=3D""> I=E2=80=99m almost positive = all the packages are compare (texinfo might have<br class=3D""> = an extra split) but you can not put dpkg into the 10.5 = tree since<br class=3D""> it=E2=80=99ll break deb = compat. This branch needs a new tree then it can be<br class=3D""> = added.<br class=3D""> ---<br = class=3D""> TS<br class=3D""> <a = href=3D"http://www.southofheaven.org/" = class=3D"">http://www.southofheaven.org/</a><br class=3D""> = Life begins and ends with chaos, live between the = chaos!<br class=3D""> On Aug 28, 2020, at 9:59 AM, = Alexander Hansen<br class=3D""> <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br class=3D""> = On Aug 28, 2020, at 02:42, Hanspeter Niederstrasser<br = class=3D""> <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br class=3D""> = What's the upgrade process for the dpkg1.16 branch and = the dists<br class=3D""> tree?<br class=3D""> = Several packages are now essential (e.g. time-date-pm = and xz) and<br class=3D""> will have to be moved from = their present subfolders in dists to<br class=3D""> = 'base'. Also, some base packages have newer versions = than what's<br class=3D""> in the dpkg1.16 branch = source (e.g. libiconv and texinfo). But the<br class=3D""> = dpkg1.16 branch versions have needed changes that = might be<br class=3D""> incompatible with older fink = installs, so we can't just copy<br class=3D""> what's = currently in dist to the dpkg1.16 branch, or push the<br class=3D""> = dpkg1.16 branch versions directly into dists. Or are = dpkg1.16<br class=3D""> packages compatible with = legacy dpkg?<br class=3D""> Hanspeter<br class=3D""><br = class=3D""><br class=3D""> At minimum, the most = logical thing to do would be to update<br class=3D""> = libiconv, texinfo, et. al. in the dpkg1.16 branch and = also apply the<br class=3D""> branch-specific changes = - i.e. merge them in a logical sense if not<br class=3D""> = in a Git sense. I hate to say it, but this might = be a case for a<br class=3D""> new distro and clean = reinstall rather than update in place. I know<br class=3D""> = we just did that for Catalina, but my impression is = that Big Sur is<br class=3D""> going to change a bunch = of stuff.<br class=3D""> --<br class=3D""> = Alexander Hansen, Ph.D.<br class=3D""> = Fink User Liaison<br class=3D""> = _______________________________________________<br = class=3D""> fink-core mailing list<br class=3D""> = <a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br class=3D""> = List archive:<br class=3D""> <a = href=3D"http://news.gmane.org/gmane.os.apple.fink.core" = class=3D"">http://news.gmane.org/gmane.os.apple.fink.core</a><br = class=3D""> Subscription management:<br class=3D""> = <a = href=3D"https://lists.sourceforge.net/lists/listinfo/fink-core" = class=3D"">https://lists.sourceforge.net/lists/listinfo/fink-core</a><br = class=3D""><br class=3D""><br class=3D""> = _______________________________________________<br = class=3D""> fink-core mailing list<br class=3D""> = <a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br class=3D""> = List archive:<br class=3D""> <a = href=3D"http://news.gmane.org/gmane.os.apple.fink.core" = class=3D"">http://news.gmane.org/gmane.os.apple.fink.core</a><br = class=3D""> Subscription management:<br class=3D""> = <a = href=3D"https://lists.sourceforge.net/lists/listinfo/fink-core" = class=3D"">https://lists.sourceforge.net/lists/listinfo/fink-core</a><br = class=3D""><br class=3D""><br class=3D""><br class=3D""><br class=3D""><br= class=3D""><br class=3D""><br class=3D""><br class=3D""><br class=3D""> = _______________________________________________<br = class=3D""> fink-core mailing list<br class=3D""> = <a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br class=3D""> = List archive:<br class=3D""> <a = href=3D"http://news.gmane.org/gmane.os.apple.fink.core" = class=3D"">http://news.gmane.org/gmane.os.apple.fink.core</a><br = class=3D""> Subscription management:<br class=3D""> = <a = href=3D"https://lists.sourceforge.net/lists/listinfo/fink-core" = class=3D"">https://lists.sourceforge.net/lists/listinfo/fink-core</a><br = class=3D""><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">_______________________________________________<br = class=3D"">fink-core mailing list<br class=3D""><a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br class=3D"">List = archive:<br class=3D"">http://news.gmane.org/gmane.os.apple.fink.core<br = class=3D"">Subscription management:<br = class=3D"">https://lists.sourceforge.net/lists/listinfo/fink-core<br = class=3D""></div></div></blockquote></div><br = class=3D""></div></body></html>= --Apple-Mail=_8C5A79BF-5AFA-47B6-88A3-570A7EC81020-- --===============6179540617720238727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6179540617720238727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ fink-core mailing list [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core --===============6179540617720238727==--