Groups | Search | Server Info | Login | Register
Groups > linux.debian.policy > #9363
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.policy |
| Subject | Bug#301011: #301011 - more verbose instructions on new upstream package |
| Date | 2026-05-13 12:40 +0200 |
| Message-ID | <MUfap-4OjJ-7@gated-at.bofh.it> (permalink) |
| References | <MU2wy-4FYA-5@gated-at.bofh.it> <MU2wy-4FYA-3@gated-at.bofh.it> <MU2wy-4FYA-5@gated-at.bofh.it> <MU2wy-4FYA-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
[Multipart message — attachments visible in raw view] - view raw
hi serafi, On Tue, May 12, 2026 at 11:07:32PM +0200, Serafeim (Serafi) Zanikolas wrote: > tags 301011 + patch once again, thanks for the patch! I only have one issue with it: (and some minor ones) > +To update a package for a new upstream release: [...] > +2. Diff the old and new upstream sources (e.g. with ``diff -urN`` or ``git`` > + equivalent) to get a feel for the scope of the changes, where work is actively > + being done (and thus where new bugs may appear), and also keep an eye out for > + anything suspicious. this doesnt sound like one should review the whole diff, which is what we should recommend to do first, if possible and only if thats not possible because the changes are too big, one should fall back to strategies like the above. also it might be useful to give suggestions how to filter out .po files etc > +3. Port the old Debian packaging to the new version. This basically involves > + merging ``debian/patches`` from the old package to the new one and incrementing > + the ``debian/changelog``. i'd reverse the order: increment d/changelog and (if applicable) merge/update d/patches. > +6. If any changes were made to the build system (hopefully you'd know from steps > + 1 and 2), update the ``debian/rules`` and ``debian/control`` build > + dependencies if necessary. drop the hopefully? > +7. Build the new package in a chroot, e.g. using ``pbuilder``. A chroot ensures > + that all required build dependencies are listed in ``debian/control``, and > + eliminates the possibility of interference of any third party packages in > + your system. chroot is a specific tool. "isolated environment" is a better more general term, also sbuild's unshare mode doesnt need a chroot :) in general i would probably recommend sbuild over pbuilder these days, and definitly\ I would mention both. that said, this is very good patch already, thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's not climate change nor climate crisis, it's climate disaster.
Back to linux.debian.policy | Previous | Next — Previous in thread | Next in thread | Find similar
Bug#301011: #301011 - more verbose instructions on new upstream package "Serafeim (Serafi) Zanikolas" <sez@debian.org> - 2026-05-12 23:10 +0200
Bug#301011: #301011 - more verbose instructions on new upstream package Holger Levsen <holger@layer-acht.org> - 2026-05-13 12:40 +0200
Bug#301011: #301011 - more verbose instructions on new upstream package "Serafeim (Serafi) Zanikolas" <sez@debian.org> - 2026-05-13 22:50 +0200
csiph-web