elbepack: aptpkgutils: implement recursive package blacklisting in diet builds by Taumille · Pull Request #453 · Linutronix/elbe

Taumille · 2025-12-17T13:54:30Z

Implements package blacklisting for diet builds, this allows the user to create a list of packages to exclude from the target. This will recursively avoid installing a package and all its dependencies on the target even if this package comes as a dependency of another package.
This must be carefully used as it can create packages with lacking dependencies.

This pull-request conflict with #451 that removes the part of the documentation on target package blacklisting

t-8ch

Did you also try to use the existing tighten mode, which ignores dependencies completely?

FYI I am about to pick up #451, so you'll need to rebase for that and adapt the docs for it.

t-8ch · 2026-01-02T10:09:51Z

elbepack/aptpkgutils.py



-def getalldeps(c, pkgname):
+def getalldeps(c, pkgname, blacklist=[]):


Mutable default arguments are problematic, as any mutation will persist between function invocations.
While this won't happen here, it is still a red flag.

Use an empty tuple () instead.

t-8ch · 2026-01-02T10:10:38Z

elbepack/schema/dbsfed.xsd

+        <element name="target" type="rfs:pkg-list" minOccurs="0" maxOccurs="unbounded">
+          <annotation>
+            <documentation>
+              avoid installing the specified packages into the target


Please mention that it only works for diet builds.

t-8ch · 2026-01-02T10:12:28Z

elbepack/efilesystem.py


        if xml.tgt.has('diet'):
+            if xml.has('target/pkg-blacklist/'):
+                blacklist = [p.et.text for p in xml.node('target/pkg-blacklist/target')]


Instead of silently ignoring the entry for non-diet builds, please throw an error instead.

t-8ch · 2026-01-02T10:17:48Z

elbepack/efilesystem.py

            for p in pkglist:
-                deps = cache.get_dependencies(p)
+                if p in blacklist:
+                    continue


Instead of having multiple places checking the blacklist, IMO it would be cleaner to move all the blacklist checking into cache.get_dependencies() by also having it return the original package and drop the withdeps += [p] below.

Taumille · 2026-01-05T10:16:03Z

Hello @t-8ch, thank you for the review. Sadly tighten remove all dependencies for all packages.

My use case is specifically for packages coming from an unofficial source (ROS2 packages). Those packages may be incorrectly written and, in my case, tend to use the Depends tag for everything even what should be tagged as only Recommends.

This result in the fact that downloading a ROS package for a Lidar will download all the useless debugging and visualization tools for it, Qt packages to run those apps and a bunch of display related packages.

Using the tighten directive would force me to recursively search by hand for each and every needed dependencies for all my official packages which would be a painful step just to fix a bad package.

t-8ch · 2026-01-05T10:50:04Z

I see. On the other hand having to maintain special logic in ELBE only to account for those broken packages is undesirable from my perspective.
Looking at the file you linked, it seems they do try to make different components usable somewhat independently.
Maybe they are unaware about the issue and willing to fix it on their side? Did you report the issue to them?

Taumille · 2026-01-05T14:12:52Z

I see. On the other hand having to maintain special logic in ELBE only to account for those broken packages is undesirable from my perspective.

Understandable, however I think that my use case is one of a long list of potential ones for this feature.
As Debian is a binary distribution we probably have a lot of packages built with all their features but where the user may only wants some of them because he care for the disk space but doesn't for broken dependencies.
Moreover in the end it will probably end up being a 10 line feature.

Looking at the file you linked, it seems they do try to make different components usable somewhat independently.
Maybe they are unaware about the issue and willing to fix it on their side? Did you report the issue to them?

Indeed, I didn't report the issue, it is probably linked to the way ROS automatically creates debian packages.

This reverts commit 98a0c58.

t-8ch · 2026-01-05T15:22:53Z

I think that my use case is one of a long list of potential ones for this feature.

So far non of them have come up :-)

Moreover in the end it will probably end up being a 10 line feature.

Implementing the feature won't be that big of a problem. Having to maintain it however, I'd like to avoid.

Indeed, I didn't report the issue, it is probably linked to the way ROS automatically creates debian packages.

Please do report it.

Taumille · 2026-01-05T16:02:43Z

Implementing the feature won't be that big of a problem. Having to maintain it however, I'd like to avoid.

Ok, I understand, so do you want me to close the PR ? or are you interested in the feature ?
If it becomes hard to maintain the feature at some point isn't it possible to drop it ?

Please do report it.

I will, (first I need to understand in depth why it exists)

t-8ch · 2026-01-05T16:08:48Z

so do you want me to close the PR ?

Leave it open for now, please.

If it becomes hard to maintain the feature at some point isn't it possible to drop it ?

Maintaining it properly would require the addition of new testcases. And these need to be written and then run all the time.
Without them it will just silently break at some point. Also removing the feature would break users workflows which I'd like to avoid.

Taumille · 2026-01-05T16:14:18Z

Maintaining it properly would require the addition of new testcases. And these need to be written and then run all the time. Without them it will just silently break at some point.

If needed, I can spend some times creating a test case and include it in the PR

…et builds Implements package blacklisting for diet builds, this allows the user to create a list of packages to exclude from the target. This will recursively avoid installing a package and all its dependencies on the target even if this package comes as a dependency of another package. This must be carefully used as it can create packages with lacking dependencies. Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>

t-8ch requested changes Jan 2, 2026

View reviewed changes

Revert "dbsfed.xsd: remove artifacts from old documentation"

d50f56f

This reverts commit 98a0c58.

Taumille force-pushed the package_blacklisting branch 2 times, most recently from cbcc124 to 53c4e2c Compare January 5, 2026 15:21

Taumille force-pushed the package_blacklisting branch from 53c4e2c to da20aba Compare January 5, 2026 16:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

elbepack: aptpkgutils: implement recursive package blacklisting in diet builds#453

elbepack: aptpkgutils: implement recursive package blacklisting in diet builds#453
Taumille wants to merge 2 commits intoLinutronix:masterfrom
Taumille:package_blacklisting

Taumille commented Dec 17, 2025

Uh oh!

t-8ch left a comment

Uh oh!

t-8ch Jan 2, 2026

Uh oh!

t-8ch Jan 2, 2026

Uh oh!

t-8ch Jan 2, 2026

Uh oh!

t-8ch Jan 2, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants



		def getalldeps(c, pkgname):
		def getalldeps(c, pkgname, blacklist=[]):

Comments

Conversation

Taumille commented Dec 17, 2025

Uh oh!

t-8ch left a comment

Choose a reason for hiding this comment

Uh oh!

t-8ch Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

t-8ch Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

t-8ch Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

t-8ch Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

t-8ch commented Jan 5, 2026

Uh oh!

Taumille commented Jan 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants