Re: RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

On Wed, 6 Nov 2024 22:55:43 +
Colin Watson  wrote:

> On Wed, Nov 06, 2024 at 04:06:59PM -0600, Aaron Rainbolt wrote:
> > (Side note, I wonder if there's a way to implement Weak-Depends that
> > *doesn't* require modifying all of the tons of packages Johannes
> > mentioned. Maybe some way of annotating packages in Recommends as
> > "important" would permit a distinction to be made here in such a way
> > that most tools wouldn't need changes? Those that were updated
> > would be able to understand the distinction, those that weren't
> > would continue to treat Recommends the same way they do today. No
> > idea if that's feasible, just something that went through my head.)
> >  
> 
> In some ways I think what we're missing is really a way to do the
> equivalent of "extras" in Python packages
> (https://peps.python.org/pep-0508/#extras): effectively groups of
> additional dependencies to enable some kind of feature that you can
> opt into if you need that feature, rather than having to pick from an
> undifferentiated pile of Recommends, or do things like devscripts does
> where you explain the Recommends you need for various tools in your
> package description (and hope that they never change, because people
> might not know that they need to keep up).
>
> I don't think the proposed Weak-Depends particularly helps with that;
> it adds another fine gradation along the axis of "how important is
> this dependency", rather than considering the orthogonal axis of
> "what is this dependency for".

That's a good point, and with a solution that focused on what
dependencies are for, one could prevent severe issues by marking a
dependency as "basic", i.e. without this, basic functionality breaks or
is very likely to break. That could be used for things like
dracut's dependency on systemd-cryptsetup or live-config's dependencies
on sudo and user-setup. Then the user could choose the extra
functionality they wanted on a package-by-package basis.

There are two kinds of categorization here that should be taken into
account - there's the way a package perceives its dependencies, and the
way a package perceives itself. For instance, diffoscope may perceive
mono-runtime primarily as a tool for disassembling .NET applications
into CIL bytecode, while other packages may perceive it primarily as a
runtime environment. The way in which a package perceives itself is
already handled in Debian (to some degree at least) by the sections
mechanism and the priority field, while it sounds like you're talking
specifically about how packages perceive other packages, for instance
diffoscope could declare its dependency on mono-runtime as being in a
group of recommends called "code-disassemblers" or whatever. Is that
right?

> In most cases you can get around this sort of thing using some extra
> metapackages.  This is usually workable, but since it involves a trip
> through NEW people are reluctant to do it too much, and it contributes
> to Packages bloat.
> 
> Still, I entirely agree with those who've said that adding new package
> relationship fields is a _lot_ of work and should have a very high
> bar, and the same goes for extending the syntax of existing fields.
> Not to mention that we're kind of running out of convenient ASCII
> punctuation characters.

Agreed. Still though, if a good theoretical solution is found here, I'm
willing to at least try implementing it even if it does end up being a
lot of work to bring it to fruition.

Aaron


pgpLW15c_P7dt.pgp
Description: OpenPGP digital signature

Re: RFC: "Recommended bloat", and how to possibly fix it

[Charles Plessy]

Hello Aaron and everybody,

the R package ecosystem uses control fields inspired by ours.  But there
the Suggests field is used in a stronger way: packages listed in
Suggests usually provide functionality that is directly leveraged by
packaged code, and the usual pattern is that if the suggested package is
not installed, there is error catching that leads to a less prefered
alternative or to a message with guidance about installing the suggested
package.

In Debian, if I remember well, I have seen that kind of behaviour with
Inkskape opening a pop-up requesting the installation of extra python
packages when trying to use some filters.

The Suggests field in Debian is not very useful at the moment, but there
is a straightforward way to repurpose it.  And apt-get already has
an --install-suggests option.

Have a nice day,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Re: RFC: "Recommended bloat", and how to possibly fix it

[IOhannes m zmölnig]

Am 6. November 2024 00:35:59 MEZ schrieb Aaron Rainbolt :
>
>
>* Add a "Weak-Depends" field to the list of binary dependency control
>  fields in the Debian Policy Manual section 7.2, with a definition
>  very similar to the existing definition for "Recommends".
>* Change the definition of the "Recommends" field to match the way
>  the field is oftentimes used in the Debian archive.


This awfully reminds me of xkcd927 (even though it's not a good analogy).

Afaict, the problem is that we have 3 options to pick from, and it's hard for 
people to decide which is the "right one".
I do not see how adding a 4th option will make this decision any easier (esp. 
since that new option is so similar to an already existing one).

Just my 2¢


mfh.her.fsr
IOhannes

Re: diffoscope dependency granularity [was RFC: "Recommended bloat", and how to possibly fix it]

[Richard Lewis]

Fay Stegerman  writes:

> [Added diffosc...@lists.reproducible-builds.org to Cc]
>
> * Fay Stegerman  [2024-11-06 17:43]:
>> * Johannes Schauer Marin Rodrigues  [2024-11-06 02:28]:
>> [...]
>> > Have one package diffoscope and one package diffoscope-full and you could 
>> > even
>> > have a package diffoscope-minimal and there you have user-selectable
>> > granularity.
>> 
>> We already have two diffoscope packages for exactly this reason (I work on
>> diffoscope and only have -minimal installed myself):
>> 
>> $ apt-cache show diffoscope/sid | grep -A1 full
>>  This is a dependency package that recommends the full set of external tools,
>>  to support as many type of files as possible.
>> 
>> $ apt-cache show diffoscope-minimal/sid | grep -A2 partial
>>  This -minimal package only recommends a partial set of the supported 3rd 
>> party
>>  tools needed to produce file-format-specific comparisons, excluding those 
>> that
>>  are considered too large or niche for general use.
>
> IMO in the case of diffoscope it could make sense to have multiple tools
> metapackages, like a diffoscope-tools-android etc., to both make it easier to
> avoid those dependencies if you know you don't need them, but also to easily
> install the dependencies for the file formats you do work with.

I think even diffoscope-minimal pulls in too much - all i wanted was a
better version of debdiff, but diffoscope-minimal recommends things like
openssl, openssh-client, r-base-core which seem well beyong "minimal" --
but you cant just purge all its recommends as some (like xz-utils) are
needed for other reasons.

Bug#1086871: ITP: rust-auto-impl -- auto-traits for pointers and closures

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-auto-impl
  Version : 1.2.0
  Upstream Contact: https://github.com/auto-impl-rs/auto_impl/issues
* URL : https://github.com/auto-impl-rs/auto_impl
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : auto-traits for pointers and closures

 auto_impl is a proc-macro attribute
 for automatically implementing a trait
 for references, some common smart pointers and closures.
This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsa, at
.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmcr1gUMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhfsUP/2A+4B/kH65D5htz31BhudST0POEsQpOfKqT/ShS
NhWIqJgbthNs1AN/7Avj+QDttUYrABDBs9UcZi+3fKlS2p3LssoqtMaw2HxfGUvz
STINnwIyJz+4ErDKTYrap2IcYC7S/9NvCEzQa6gBLEaHe/OWLLb6GMjcDEfTdTBX
zdZDuHBZvcxNjC5RL4SRwzJZqp6uwuxwDRSrHfb9GcDJUALXY0wyQGqmV+tIS7vF
sHaxMiPQyWolr8UDCP6W3u3WqO8khrDk7HtrflHcz17j0HPRUXWsGnzuCIM3j5WT
WHkOI92NBGPEtn+5hle4WZWDOJ+WiGpfhvNA2wZeFv2Dt0XVLuvrZ5MINU5NnNPD
FyabATh7qCPPguG0cQLUNfFdSjTbthmxhzhgzx5aenWrHkG88PtlZTlY/3IOgMHO
Cl7VGniS7Z4sVL/vfUadia+bVYmHmE0UmUNYvhkVI6MUADAeoQTpLchn5qemZ8rP
sT8moagjQMy61KwHy0xuSWsWPSWAU5EN7/ZQmCBQL4XsLBjLngIsw9WGhgKlN0hB
fw+O2DAa5nYjkfNY1aaA7CF0IHX01yazuhpa5mUyeygvRKrXuw5nRCO8AoOoP/GI
tGkVevJTBiKjuPSkCpANtRvMvwNgWNfzL7RbTYUaLS82O7eTtINPmc2RHzIYyIAl
drUQ
=yKi7
-END PGP SIGNATURE-

Re: Rebuilds to enable PAC and BTI support on arm64

[Emanuele Rocca]

On 2024-10-28 10:55, Sebastian Ramacher wrote:
> since dpkg 1.22.0 the additional hardening flags to enable Pointer
> Authentication (PAC) and Branch Target Identification (BTI)
> on arm64 are enabled by default.

Some more background and an update on this.

Both PAC and BTI are enabled by adding -mbranch-protection=standard to
the compiler flags. The defaults in Debian sid include such flag since
August 2023 (dpkg 1.22.0) as Sebastian said.

However PAC and BTI differ in the way they are enabled. For PAC, simply
building a program with -mbranch-protection=standard results in PAC to
be enabled. When it comes to BTI, all execution units (ie: all object
files) linked together need to have BTI in order for the resulting ELF
file to have BTI turned on. Since pretty much every program in the world
uses crtbeginS.o and crtendS.o from GCC as well as crti.o, Scrt1.o and
crtn.o from glibc, this means that only packages built with a
BTI-enabled GCC and glibc get the feature. In sid, we enabled BTI
support in gcc-14 14.1.0-4 (2024-07-10) and glibc 2.39-5 (2024-07-22).
See https://wiki.debian.org/ToolChain/PACBTI for more details.

I performed a local archive rebuild to get the list of all packages that
don't currently have BTI on, but would get it with a simple rebuild
(binNMU). I added the date of "last build" to the output just to verify
that no package was built after the end of July 2024, those should have
had BTI already. To my surprise some of the packages in the list where
last built in 2014, which is... well a long time ago!
https://people.debian.org/~ema/pac-bti/arm64-binNMUs.log

When the binNMUs started (thank you Sebastian) we had 10204 binary
packages with BTI turned on, and we are now at 18348. Once the rebuilds
are over I'll check the situation again. There's likely going to be a
long tail of packages that don't get BTI with a simple rebuild for many
reasons, including for example not using the default compiler flags.

As a final thought, given that new toolchain versions bring multiple
improvements over the years it's perhaps worth thinking about rebuilding
the archive on some sort of regular basis to make sure we get the
benefits?

  ema

Re: Rebuilds to enable PAC and BTI support on arm64

[Andreas Tille]

Am Wed, Nov 06, 2024 at 01:16:57PM + schrieb Holger Levsen:
> On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> > "Let's at least force rebuilds all packages not rebuilt since stable
> > before every freeze starts" is a popular opinion.
> 
> true. and "let's not do that" is even more popular, else why haven't we
> done this in three decades?

Changing something is just some effort.  How do you want to distinguish
the "let's not do that" opinion from the "no spare time to trigger a
change" "opinion"?

Finally we have those regular archive wide rebuilds that trigger lots of
FTBFS bugs.  I could imagine to simply upload those that pass the
rebuild tests.  Otherwise the package needs manual intervention by the
maintainer which also will end up in an upload or a testing removal.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Rebuilds to enable PAC and BTI support on arm64

[Holger Levsen]

On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> "Let's at least force rebuilds all packages not rebuilt since stable
> before every freeze starts" is a popular opinion.

true. and "let's not do that" is even more popular, else why haven't we
done this in three decades?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you upload your address book to "the cloud", I don't want to be in it.


signature.asc
Description: PGP signature

Re: Rebuilds to enable PAC and BTI support on arm64

[Andrey Rakhmatullin]

On Wed, Nov 06, 2024 at 01:16:57PM +, Holger Levsen wrote:
> On Wed, Nov 06, 2024 at 05:28:38PM +0500, Andrey Rakhmatullin wrote:
> > "Let's at least force rebuilds all packages not rebuilt since stable
> > before every freeze starts" is a popular opinion.
> 
> true. and "let's not do that" is even more popular, else why haven't we
> done this in three decades?

Doing is harder than talking, and doing something like that is much
harder than, say, fixing and uploading a package. Where can one start?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

[Colin Watson]

Source: python-catalogue
Version: 2.1.0-6
Severity: normal
X-Debbugs-Cc: Andreas Tille , debian-devel@lists.debian.org

https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked
from PyPI, but it's what we currently have in Debian.  Some of the more
recent releases (which I think are really in the same version series -
it's just that upstream changed their minds about bumping the patch
version) contain fixes that we should have in Debian; in particular
while trying to fix python-srsly I ran into a problem which I think is
fixed by
https://github.com/explosion/catalogue/commit/75f5e9c24e93b5fcc2b3e9f324d9328bc871abad.

I'm happy to do the work to get us onto a newer version, but I wanted to
check what to use for the version scheme.  Should we use
2.1.0+really2.0.10-1 or 1:2.0.10-1?  I think there'd be some
justification for an epoch here since the upstream version numbering
scheme changed (cf.
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version),
but I'm copying debian-devel as per policy on epoch proposals.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

[Guillem Jover]

Hi!

On Thu, 2024-11-07 at 01:15:08 +, Colin Watson wrote:
> Source: python-catalogue
> Version: 2.1.0-6
> Severity: normal
> X-Debbugs-Cc: Andreas Tille , debian-devel@lists.debian.org

> https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked
> from PyPI, but it's what we currently have in Debian.  Some of the more
> recent releases (which I think are really in the same version series -
> it's just that upstream changed their minds about bumping the patch
> version) contain fixes that we should have in Debian; in particular
> while trying to fix python-srsly I ran into a problem which I think is
> fixed by
> https://github.com/explosion/catalogue/commit/75f5e9c24e93b5fcc2b3e9f324d9328bc871abad.

> I'm happy to do the work to get us onto a newer version, but I wanted to
> check what to use for the version scheme.  Should we use
> 2.1.0+really2.0.10-1 or 1:2.0.10-1?  I think there'd be some
> justification for an epoch here since the upstream version numbering
> scheme changed (cf.
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version),
> but I'm copying debian-devel as per policy on epoch proposals.

The way I see it, this does not look like a version schema change to
me, upstream released a version that they then retracted:

  https://github.com/explosion/catalogue/issues/46

Given that I assume the current (non-retracted) upstream version is
going to be close to surpass the retracted one, I'd go for the +really
hack. In this case invalidating relationships for external
dependencies would not seem like a big issue, because it looks like
the yanked version is the only one that has ever been in Debian, but
it avoids the ugliness and confusion of epochs (people tend to forget
to add the epoch in relationships for example) and its stickiness,
going forward.

The other question that comes to mind is why the yanked version was
uploaded, as from that issue above it seems at that time it should
have already been marked as yanked. Perhaps we have some automated
tool that does not honor the yanked markings, which might deserve a bug
report? Andreas do you recall what tool or process you used for that?

Thanks,
Guillem

Re: Bug#1086878: python-catalogue: 2.1.0 was yanked - what version scheme should we use for 2.0.10?

[Colin Watson]

On Thu, Nov 07, 2024 at 02:42:08AM +0100, Guillem Jover wrote:
> On Thu, 2024-11-07 at 01:15:08 +, Colin Watson wrote:
> > https://pypi.org/project/catalogue/#history shows that 2.1.0 was yanked
> > from PyPI, but it's what we currently have in Debian.  Some of the more
> > recent releases (which I think are really in the same version series -
> > it's just that upstream changed their minds about bumping the patch
> > version) contain fixes that we should have in Debian; in particular
> > while trying to fix python-srsly I ran into a problem which I think is
> > fixed by
> > https://github.com/explosion/catalogue/commit/75f5e9c24e93b5fcc2b3e9f324d9328bc871abad.
> 
> > I'm happy to do the work to get us onto a newer version, but I wanted to
> > check what to use for the version scheme.  Should we use
> > 2.1.0+really2.0.10-1 or 1:2.0.10-1?  I think there'd be some
> > justification for an epoch here since the upstream version numbering
> > scheme changed (cf.
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version),
> > but I'm copying debian-devel as per policy on epoch proposals.
> 
> The way I see it, this does not look like a version schema change to
> me, upstream released a version that they then retracted:
> 
>   https://github.com/explosion/catalogue/issues/46

I guess you might or might not describe that as a change in the upstream
version numbering scheme, depending on how you interpret policy's
language.  *shrug*

> Given that I assume the current (non-retracted) upstream version is
> going to be close to surpass the retracted one, I'd go for the +really
> hack. In this case invalidating relationships for external
> dependencies would not seem like a big issue, because it looks like
> the yanked version is the only one that has ever been in Debian, but
> it avoids the ugliness and confusion of epochs (people tend to forget
> to add the epoch in relationships for example) and its stickiness,
> going forward.

I don't really have any information on whether upstream plans a 2.1.1 or
similar, but it's true it might well happen.

> The other question that comes to mind is why the yanked version was
> uploaded, as from that issue above it seems at that time it should
> have already been marked as yanked. Perhaps we have some automated
> tool that does not honor the yanked markings, which might deserve a bug
> report? Andreas do you recall what tool or process you used for that?

I'd initially misread it as being just a day or two after the yanked
version, but you're right, it was months later.  I suspect it was simply
uscan - it's using the GitHub tags rather than looking at PyPI, and the
tag was never removed, so it's hard to see how it could have known any
better.

This does leave the question of how to hide that version from uscan in
the future, since uscan doesn't make it easy to ignore specific upstream
versions and I'd prefer to avoid using opaque regex constructions to do
it.  My best idea is to use uversionmangle to turn 2.1.0 into something
like 2.0.8~pre1, but is there a better idiom?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: RFC: "Recommended bloat", and how to possibly fix it

[Soren Stoutner]

On Wednesday, November 6, 2024 8:12:29 PM MST Aaron Rainbolt wrote:
> At this point, we have two options. We can either explicitly remove all
> of the extra packages that get installed, or we can skip installing
> recommends at all. Both of these come with their own severe
> disadvantages. If we manually uninstall everything we don't need, that
> means we have to maintain a list of packages that get incorrectly
> installed, and keep it up-to-date as package dependencies in the
> archive change. On top of that, if a package happens to not uninstall
> cleanly, or it otherwise causes problems when installed or uninstalled,
> we'd have to figure out how to manually fix that, or avoid letting that
> particular package ever get installed in the first place via held
> packages or a similar mechanism. This is a rather large amount of work,
> and it's not easy to maintain.
> 
> The other option is to skip installing recommends. The reason that
> doesn't work well is because if we do that, we can't use recommends in
> our metapackages at all - anything we specify as a recommends in the
> metapackages won't end up installed. To work around that, we have to
> use depends for everything, and to do *that*, we have to basically
> reimplement the whole darn recommended packages mechanism in
> metapackages. This results in the metapackages setup that we have
> today, which can be seen at [1]. There's some "dependencies" packages,
> some "recommends" packages, a complex network between the packages to
> make things work right, and a smattering of dummy dependencies to allow
> users to override certain depends. Our current metapackages scheme has
> some rather inconsistent naming and could use a lot of improvement, but
> even under ideal conditions (like what I've proposed for Kicksecure in
> [2]), this is a lot of ugly hacks that reimplement existing apt
> features without using those features just to get around problematic
> recommends in Debian's packages. And this is likely *easier* to
> maintain than manually uninstalling everything we don't want.

This sounds like exactly the type of work I would expect a derivative 
distribution to do.  If I were in your shoes, I would probably do something 
like rebuild all packages for my derivative and host them in my own 
repositories, like Ubuntu does.  During that rebuild process, I would use some 
sort of patch process to alter the Recommends fields to suite the needs of my 
particular derivative distribution.  It would take time to setup and maintain 
such patches, but that is exactly the type of effort that is required to run a 
distribution.

> So, that's the issue we're having, and the solutions I'm pursuing
> (using Recommends differently, adding a Weak-Depends field, or
> implementing something like Python's extras like Colin was mentioning)
> are things I think would fix the problem for us and others. I'm
> definitely open to suggestions for other ways we could avoid these
> problems though.

This really is the type of problem that needs to be solved inside of your 
derivative distribution, not in Debian itself, especially in ways that makes 
Debian worse for its own users or requires a bunch of extra work for Debian's 
maintainers (like figuring out how to sort all of the Recommends into these new 
fields/extras options, which different derivatives/users would have distinct 
opinions about where they should go and would require a lot of time from 
Debian developers to get each package to a state that would make all potential 
consumers of the package happy).

I am sympathetic to the problems you are having.  And I wish you all the best 
in creating a distribution that meets the needs of your users.  Like I said 
earlier, if there are specific packages that actually have the wrong 
Recommends, I’m sure the package maintainers would welcome a bug report 
explaining why a package should be moved to Suggests.  But in most cases, what 
is currently in Recommends is what is in the best interests of Debian users.  
Unless you can point to a systematic problem with Recommends in Debian (which 
the examples you have presented so far have not shown), I don’t think upstream 
Debian is the place to fix the particular needs of your derivative 
distribution.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

On Wed, 06 Nov 2024 15:59:22 -0700
Soren Stoutner  wrote:

> On Wednesday, November 6, 2024 3:06:59 PM MST Aaron Rainbolt wrote:
> > And this brings us back to the original idea of creating a
> > Weak-Depends field. From my viewpoint, policy states that
> > Recommends is for declaring a strong (heavy emphasis on "strong"
> > here), but not absolute, dependency.  
> 
> After reading over the policy on the subject, I do agree that the
> current policy is a little vague as to what is intended.
> 
> "Recommends
> 
> This declares a strong, but not absolute, dependency.
> 
> The Recommends field should list packages that would be found
> together with this one in all but unusual installations.”
> 
> https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
> 
> What constitutes a strong dependency, or what constitutes packages
> being found together in all but unusual installations can be
> interpreted differently by different people.  I would be in favor of
> rewording the policy to be more expressly inline with how Recommends
> is currently interpreted and used by the majority of maintainers and
> users, which is that all packages that are required for expected
> functionality should be included in Recommends, even if a feature is
> only used by a subset of users.  Suggests should be for packages that
> enhance some aspect of the program, but which most users would either
> not expect to be installed automatically or are so large that a user
> should make an explicit decision to install them.

I suppose I'd argue that kamera only enhances some aspect of gwenview,
but meh, neither of us are really "right" since this is a matter of
opinion. It's probably better to look at the practical problems I and
the developers of Kicksecure are running into that inspired this thread
initially.

Kicksecure is a security-focused Debian derivative that is intended to
be essentially Debian with every reasonable security hardening feature
in existence enabled out of the box. Kicksecure is also used as the
base of Whonix, which is intended to provide anonymity features that
can be used within virtual machines. We have a number of our own
packages that we ship on our images, and we have a number of
metapackages that depend on both our own packages and many packages
from the Debian repositories.

Some of the packages Kicksecure's metapackages depend on are hard
dependencies, i.e. if they're removed, the system should be considered
broken. On the other hand, many of our packages are ones that we
believe should be present on most installations, but that a user may
legitimately want rid of. This probably sounds like a good fit for the
Depends and Recommends fields of debian/control, since it is, except
for one major issue.

When we build the Kicksecure images with recommends enabled, they end
up with *a lot* of gunk that we don't want. Some packages that end up
installed cause actual problems (user can't log in, Debian artwork
ends up appearing where it shouldn't, default terminal emulator is
hijacked by something called ZuTTY, etc.), other packages simply
increase the size of the ISO for no good reason. This is the result of
people using the Recommends field the way you're suggesting the policy
be changed to explicitly allow.

At this point, we have two options. We can either explicitly remove all
of the extra packages that get installed, or we can skip installing
recommends at all. Both of these come with their own severe
disadvantages. If we manually uninstall everything we don't need, that
means we have to maintain a list of packages that get incorrectly
installed, and keep it up-to-date as package dependencies in the
archive change. On top of that, if a package happens to not uninstall
cleanly, or it otherwise causes problems when installed or uninstalled,
we'd have to figure out how to manually fix that, or avoid letting that
particular package ever get installed in the first place via held
packages or a similar mechanism. This is a rather large amount of work,
and it's not easy to maintain.

The other option is to skip installing recommends. The reason that
doesn't work well is because if we do that, we can't use recommends in
our metapackages at all - anything we specify as a recommends in the
metapackages won't end up installed. To work around that, we have to
use depends for everything, and to do *that*, we have to basically
reimplement the whole darn recommended packages mechanism in
metapackages. This results in the metapackages setup that we have
today, which can be seen at [1]. There's some "dependencies" packages,
some "recommends" packages, a complex network between the packages to
make things work right, and a smattering of dummy dependencies to allow
users to override certain depends. Our current metapackages scheme has
some rather inconsistent naming and could use a lot of improvement, but
even under ideal conditions (like what I've proposed 

Re: RFC: "Recommended bloat", and how to possibly fix it

[Fay Stegerman]

* Johannes Schauer Marin Rodrigues  [2024-11-06 02:28]:
[...]
> Have one package diffoscope and one package diffoscope-full and you could even
> have a package diffoscope-minimal and there you have user-selectable
> granularity.

We already have two diffoscope packages for exactly this reason (I work on
diffoscope and only have -minimal installed myself):

$ apt-cache show diffoscope/sid | grep -A1 full
 This is a dependency package that recommends the full set of external tools,
 to support as many type of files as possible.

$ apt-cache show diffoscope-minimal/sid | grep -A2 partial
 This -minimal package only recommends a partial set of the supported 3rd party
 tools needed to produce file-format-specific comparisons, excluding those that
 are considered too large or niche for general use.

- Fay

Bug#1086859: ITP: swaysome -- swaysome allows better multi-output management for sway

[Florent 'Skia' Jacquet]

Package: wnpp
Severity: wishlist
Owner: Florent 'Skia' Jacquet 
X-Debbugs-Cc: debian-devel@lists.debian.org, s...@hya.sk

* Package name: swaysome
  Version : 2.1.2
  Upstream Contact: Florent 'Skia' Jacquet 
* URL : https://gitlab.com/hyask/swaysome
* License : MIT
  Programming Lang: Rust
  Description : swaysome allows better multi-output management for sway by 
namespacing sway's workspaces in "workspace groups" to easily move them from 
one output to another

I'm the original author of swaysome, and would like to see it be part of Debian.
This software is already part of Arch Linux through AUR and Void Linux. Having
it in Debian would help many sway-flavored derivatives to make use of it easily.

I use this software daily since its very beginning in 2020, and I'm not aware of
any similar package.
Here is the original post in the sway bug tracker, for a bit of history on why
this tool is useful:
https://github.com/swaywm/sway/issues/4771#issuecomment-766337073

I do intend to maintain both the upstream software and the Debian package, but I
would need a sponsor to get it uploaded.
If someone wants to help in co-maintaining, I'm not against the idea either, but
I don't expect this software to be a big burden of maintenance, so me alone
is fine.

Just for completeness, I have already done most of the work here:
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/578

diffoscope dependency granularity [was RFC: "Recommended bloat", and how to possibly fix it]

[Fay Stegerman]

[Added diffosc...@lists.reproducible-builds.org to Cc]

* Fay Stegerman  [2024-11-06 17:43]:
> * Johannes Schauer Marin Rodrigues  [2024-11-06 02:28]:
> [...]
> > Have one package diffoscope and one package diffoscope-full and you could 
> > even
> > have a package diffoscope-minimal and there you have user-selectable
> > granularity.
> 
> We already have two diffoscope packages for exactly this reason (I work on
> diffoscope and only have -minimal installed myself):
> 
> $ apt-cache show diffoscope/sid | grep -A1 full
>  This is a dependency package that recommends the full set of external tools,
>  to support as many type of files as possible.
> 
> $ apt-cache show diffoscope-minimal/sid | grep -A2 partial
>  This -minimal package only recommends a partial set of the supported 3rd 
> party
>  tools needed to produce file-format-specific comparisons, excluding those 
> that
>  are considered too large or niche for general use.

IMO in the case of diffoscope it could make sense to have multiple tools
metapackages, like a diffoscope-tools-android etc., to both make it easier to
avoid those dependencies if you know you don't need them, but also to easily
install the dependencies for the file formats you do work with.

- Fay

Bug#1086876: ITP: rust-hstr -- string type optimized for hash operations

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-hstr
  Version : 0.2.12
  Upstream Contact: 강동윤 
* URL : https://github.com/dudykr/ddbase
* License : Apache-2.0
  Programming Lang: Rust
  Description : string type optimized for hash operations

 hstr is a high-performance string interning library for Rust.
 This crate is intended for the compilers
 or build tools like a bundler, written in Rust.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsa, at
.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmcr8XsMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh24IP/ROB18dSt7oQXWhXvA5/ZvWxscwgaOueVmZVmbC9
wRWyufufbqm3j/tgHcSEcOm809svSS2D9OG1l1xL28eLemPSkZF8tzWb01G1GlZC
Wb39rTRXuLm66ArpmtbCq46FjIzcjC45kBJufO8IKrhgJKDnjEVGK9aNWP4Ti9qF
i5szWJ9dY2K5wjJNgiBQQHKo46PVXaNanXlJ2mLarWLyoB0M/fCW0vUkEpxduZUv
2pYJgidA4CJPV0jPUFlyOiAsBmohTCCQMy+XDJAF++GTMQtLUgv+nZaQ6in2A9pe
h4NbwqeuT75AI/AUj9PB6jzgmcMWUu6DZDnjCMUvCr5zMR0PO/DiwdP9s+9mdz8j
4OUnajE3U97E4/hUsQfi8ErWnqwwT25Z66ZqUsTEjXv7j0sO8AWmQ7y6a8teFZPp
vZmXb4pdEzw8tUibFHwnSzkapHwAk9WyStVAo2B9C7fVDIxp/O1xNZv2769erm+f
0iX5PuqyqisYl5GOoKD9TIbpO6r06+0LtB/UcqmGX68ZlfnE2zf2vskIiRJOY3cn
1UdG1v9TVeiq2ftt1W/s3uv214HV+K3EEgU2vdrxdETGFmJ4EB39ajGiX46XVyVF
CZDpADBxHdQXZropz1lsDaBzdDnF9GGEBTfJPDBVp5FQt536K33LK5mMrrGz+DBi
e3vB
=257D
-END PGP SIGNATURE-

Re: RFC: "Recommended bloat", and how to possibly fix it

[Colin Watson]

On Wed, Nov 06, 2024 at 04:06:59PM -0600, Aaron Rainbolt wrote:
> (Side note, I wonder if there's a way to implement Weak-Depends that
> *doesn't* require modifying all of the tons of packages Johannes
> mentioned. Maybe some way of annotating packages in Recommends as
> "important" would permit a distinction to be made here in such a way
> that most tools wouldn't need changes? Those that were updated would be
> able to understand the distinction, those that weren't would continue
> to treat Recommends the same way they do today. No idea if that's
> feasible, just something that went through my head.)

In some ways I think what we're missing is really a way to do the
equivalent of "extras" in Python packages
(https://peps.python.org/pep-0508/#extras): effectively groups of
additional dependencies to enable some kind of feature that you can opt
into if you need that feature, rather than having to pick from an
undifferentiated pile of Recommends, or do things like devscripts does
where you explain the Recommends you need for various tools in your
package description (and hope that they never change, because people
might not know that they need to keep up).

I don't think the proposed Weak-Depends particularly helps with that; it
adds another fine gradation along the axis of "how important is this
dependency", rather than considering the orthogonal axis of "what is
this dependency for".

In most cases you can get around this sort of thing using some extra
metapackages.  This is usually workable, but since it involves a trip
through NEW people are reluctant to do it too much, and it contributes
to Packages bloat.

Still, I entirely agree with those who've said that adding new package
relationship fields is a _lot_ of work and should have a very high bar,
and the same goes for extending the syntax of existing fields.  Not to
mention that we're kind of running out of convenient ASCII punctuation
characters.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: RFC: "Recommended bloat", and how to possibly fix it

[Soren Stoutner]

On Wednesday, November 6, 2024 3:06:59 PM MST Aaron Rainbolt wrote:
> And this brings us back to the original idea of creating a Weak-Depends
> field. From my viewpoint, policy states that Recommends is for
> declaring a strong (heavy emphasis on "strong" here), but not absolute,
> dependency.

After reading over the policy on the subject, I do agree that the current 
policy is a little vague as to what is intended.

"Recommends

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together with 
this one in all but unusual installations.”

https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

What constitutes a strong dependency, or what constitutes packages being found 
together in all but unusual installations can be interpreted differently by  
different people.  I would be in favor of rewording the policy to be more 
expressly inline with how Recommends is currently interpreted and used by the 
majority of maintainers and users, which is that all packages that are 
required for expected functionality should be included in Recommends, even if 
a feature is only used by a subset of users.  Suggests should be for packages 
that enhance some aspect of the program, but which most users would either not 
expect to be installed automatically or are so large that a user should make 
an explicit decision to install them.

There probably are some packages that have items in Recommends that should 
actually be in Suggests.  I once received a bug report from a user asking me 
to move a package from Recommends to Suggests, which suggestion I agreed with 
and was grateful for receiving.  But personally, I would find an additional 
category unnecessary and even confusing, especially because users already have 
the option to not auto-install recommended packages if they really don’t want 
them (which usually comes down to space-saving concerns, especially on 
embedded systems).

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

On Wed, 06 Nov 2024 21:41:43 -0700
Soren Stoutner  wrote:

> On Wednesday, November 6, 2024 8:12:29 PM MST Aaron Rainbolt wrote:
> > At this point, we have two options. We can either explicitly remove
> > all of the extra packages that get installed, or we can skip
> > installing recommends at all. Both of these come with their own
> > severe disadvantages. If we manually uninstall everything we don't
> > need, that means we have to maintain a list of packages that get
> > incorrectly installed, and keep it up-to-date as package
> > dependencies in the archive change. On top of that, if a package
> > happens to not uninstall cleanly, or it otherwise causes problems
> > when installed or uninstalled, we'd have to figure out how to
> > manually fix that, or avoid letting that particular package ever
> > get installed in the first place via held packages or a similar
> > mechanism. This is a rather large amount of work, and it's not easy
> > to maintain.
> > 
> > The other option is to skip installing recommends. The reason that
> > doesn't work well is because if we do that, we can't use recommends
> > in our metapackages at all - anything we specify as a recommends in
> > the metapackages won't end up installed. To work around that, we
> > have to use depends for everything, and to do *that*, we have to
> > basically reimplement the whole darn recommended packages mechanism
> > in metapackages. This results in the metapackages setup that we have
> > today, which can be seen at [1]. There's some "dependencies"
> > packages, some "recommends" packages, a complex network between the
> > packages to make things work right, and a smattering of dummy
> > dependencies to allow users to override certain depends. Our
> > current metapackages scheme has some rather inconsistent naming and
> > could use a lot of improvement, but even under ideal conditions
> > (like what I've proposed for Kicksecure in [2]), this is a lot of
> > ugly hacks that reimplement existing apt features without using
> > those features just to get around problematic recommends in
> > Debian's packages. And this is likely *easier* to maintain than
> > manually uninstalling everything we don't want.  
> 
> This sounds like exactly the type of work I would expect a derivative 
> distribution to do.  If I were in your shoes, I would probably do
> something like rebuild all packages for my derivative and host them
> in my own repositories, like Ubuntu does.  During that rebuild
> process, I would use some sort of patch process to alter the
> Recommends fields to suite the needs of my particular derivative
> distribution.  It would take time to setup and maintain such patches,
> but that is exactly the type of effort that is required to run a
> distribution.

I'm not sure why this would be a reasonable solution here. Kicksecure
already has a solution that is working. We dislike it, and I'd like for
something better to exist, but our metapackage tricks work for the time
being.

To be clear, I am not just doing this because I have a job to do and
this is part of it. I'm doing this because I truly believe that
Debian's current "recommended bloat" issues are a problem within Debian
itself and are worth my time and effort to solve. With that in mind,
bringing into the picture what a derivative should or shouldn't do
isn't really relevant to the discussion at hand. Much like the
diffoscope example, Kicksecure's issues were intended to be an example,
not a definition of an end goal.

> > So, that's the issue we're having, and the solutions I'm pursuing
> > (using Recommends differently, adding a Weak-Depends field, or
> > implementing something like Python's extras like Colin was
> > mentioning) are things I think would fix the problem for us and
> > others. I'm definitely open to suggestions for other ways we could
> > avoid these problems though.  
> 
> This really is the type of problem that needs to be solved inside of
> your derivative distribution, not in Debian itself, especially in
> ways that makes Debian worse for its own users or requires a bunch of
> extra work for Debian's maintainers (like figuring out how to sort
> all of the Recommends into these new fields/extras options, which
> different derivatives/users would have distinct opinions about where
> they should go and would require a lot of time from Debian developers
> to get each package to a state that would make all potential
> consumers of the package happy).

There's no reason this exact issue couldn't happen in Debian itself.
Any metapackage system that encourages its users to use
--no-install-recommends to avoid installation of unnecessary packages
is going to run into the exact same problem, whether inside of Debian
or outside of it. For that matter, any Debian user who uses
--no-install-recommends with a metapackage that uses Recommends is
going to run into the same kind of problem.

> I am sympathetic to the problems you are having.  And I wish you all
> the best in creating a d

Bug#1086882: ITP: gtk-meshtastic-client -- A GTK GUI for meshtastic Devices

[Chris Talbot]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Christopher Talbot 
Severity: wishlist

* Package name: gtk-meshtastic-client
  Version : 0.1.0
  Upstream Contact: Christopher Talbot 
* URL : https://www.example.org/
* License : GPL 3.0
  Programming Lang: Python
  Description : A GTK GUI for Meshtastic Devices

This is a GTK GUI client for meshtastic devices, built on top of the
python library meshtastic that is already packaged. This is the only
known GUI for Linux first devices. I can maintain packaging and would
like to be sponsored by the Debian Hamradio Maintainers (I spoke with
Hibby about sponsoring the package)

Thank you!

--Chris

Re: RFC: "Recommended bloat", and how to possibly fix it

[Sune Vuorela]

On 2024-11-06, Colin Watson  wrote:
> In some ways I think what we're missing is really a way to do the
> equivalent of "extras" in Python packages
> (https://peps.python.org/pep-0508/#extras): effectively groups of
> additional dependencies to enable some kind of feature that you can opt
> into if you need that feature, rather than having to pick from an

And conditional dependencies/recommends. Maybe they're kind of the same:

Package: foo
Recommends: foo-l10n-de[language-de]

Package: libQtGui
Depends: libQtWayland[gui-thingie-wayland], libQtX11[gui-thingie-x11]

Package: php
Depends: php-apache2-glue[apache2-is-installed],
php-nginx-glue[nginx-is-installed]

But I think this is kind of just dreaming at this point.

/Sune

Re: RFC: "Recommended bloat", and how to possibly fix it

[Soren Stoutner]

On Wednesday, November 6, 2024 10:41:46 PM MST Aaron Rainbolt wrote:
> Again, this isn't a problem limited to a derivative distribution. I
> respect that your opinion of how Recommends should work differs from
> mine. That doesn't change the policy though, and it doesn't change that
> neglecting or changing the policy's rules in this area will cause and
> is causing problems to some of Debian's users. Ultimately I don't care
> exactly how those problems are solved, I just want to solve them.

Let me try to explain what I see as the core of the problem.

First, some background on the three existing categories.

1.  Depends:  These are the packages necessary to install and run the basic 
functionality of 
the package.

2.  Recommends:  These are the packages required to enable all the features of 
the 
package.

3.  Suggests:  These are packages that enhance the functionality of the package.

Enabling a feature in the package is a "strong dependency”, which is what is 
meant by the 
policy.  I agree that it could be worded in such a way as to be more clear to 
some people, 
particularly if they are not familiar with Debian or for whom English is not 
their primary 
language, but I want to be clear that the way I have defined Recommends above 
is exactly 
what the current policy envisions (at least I believe that is the understanding 
of the 
majority of the Debian community).

When a user installs a package and all the Recommends, they should be able to 
expect 
that all of the features of the package should just work.  They should not have 
to go 
hunting down some other package to install to enable one of the features of the 
package, 
even if that feature is less commonly used.

Some packages are clearly in Depends, Recommends, or Suggests.  Others might be 
right 
on the line between two of the categories.  In these cases, a maintainer has to 
make a 
judgement call.  If a user thinks they have got it wrong, they are welcome to 
submit a bug 
report explaining why they think it should be in the other category.

Some upstream projects are complex enough that the above three categories don’t 
fully 
capture the needs of users.  In those cases, meta-packages can accommodate 
those 
needs, as has already been discussed (which is analogous to Python "extras").  
If a user 
believe there is a compelling case to be made for an additional meta-package, 
they should 
feel free to file a bug report and explain the merits of their request.

With all of that said as background, the reason why I am opposed to what you 
are 
requesting is that it boils down to:  "Please create a package category that 
only installs the 
important features instead of all the ones I don’t use”.  This category would 
be somewhere 
in between Depends (the packages necessary to run the basic functionality) and 
Recommends (the packages necessary to run all the functionality).

What I don’t like about this idea is it requires the package maintainer to be a 
mind reader.  
Specifically, they need to read *your* mind, because every single user has a 
different list 
of what the “important” functionality is.  What you or your distribution 
considers important 
the next user or distribution would say, “I never use that, take it out.  But I 
need this other 
thing.”

Maintainers would end up having to create multiple variations of each package 
to make 
everyone happy.  It is unsustainable.  If you, as a user, want something 
between the basic 
functionality and all the functionality, please just install the basic 
functionality (Depends) 
and then add the extra functionality that is important to you.  Don’t ask the 
package 
maintainer to read you mind and guess at what that will be.

signature.asc
Description: This is a digitally signed message part.

Re: RFC: "Recommended bloat", and how to possibly fix it

[Holger Levsen]

On Wed, Nov 06, 2024 at 06:03:45PM +0100, IOhannes m zmölnig wrote:
> Afaict, the problem is that we have 3 options to pick from, and it's hard for 
> people to decide which is the "right one".
> I do not see how adding a 4th option will make this decision any easier (esp. 
> since that new option is so similar to an already existing one).
 
absolutly.

maybe the problem is also related that the original poster didn't know about
the diffoscope-minimal package because it's non obvious and somewhat hard
to find?

$ apt-cache search minimal|cut -d ' ' -f1|grep minimal$
cm-super-minimal
diffoscope-minimal
gdb-minimal
haskell-devscripts-minimal
keepassxc-minimal
kde-telepathy-minimal
python3-minimal
libpython3.12-minimal
python3.12-minimal
libpython3.13-minimal
python3.13-minimal
virtuoso-minimal

are there other similar metapackages?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Faschisten hören niemals auf, Faschisten zu sein
Man diskutiert mit ihnen nicht, hat die Geschichte gezeigt“...


signature.asc
Description: PGP signature

Re: Rebuilds to enable PAC and BTI support on arm64

[Andrey Rakhmatullin]

On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
> As a final thought, given that new toolchain versions bring multiple
> improvements over the years it's perhaps worth thinking about rebuilding
> the archive on some sort of regular basis to make sure we get the
> benefits?

"Let's at least force rebuilds all packages not rebuilt since stable
before every freeze starts" is a popular opinion.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1086863: ITP: rust-swc-core -- speedy web compiler - Rust source code

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-swc-core
  Version : 5.0.2
  Upstream Contact: 강동윤 
* URL : https://github.com/swc-project/swc
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : speedy web compiler - Rust source code

 swc is a typescript / javascript transpiler.
 It consumes JavaScript or TypeScript files
 written in one version of these languages
 and emits javascript code
 which can be executed on JavaScript engines
 that are not yet supporting latest features.
 .
 swc is written in Rust,
 and is an order a magnitude faster
 than similar projects written in JavaScript.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsa, at
.

-BEGIN PGP SIGNATURE-

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmcrr40MHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEh58wP/R97R8gbjqfRXFMtXjEPUsHKrNk0bKQsPcEx29Mj
g5priaxhvwwVLedQxYTrgQL1YYhxYMBPCz98R1Zjm2/E5CzSqU/4x/Wh58N4oO+G
eooym3TyeCwgWRi67dXBvN1z9FDOdTWmPxk26vECj1DrTz4chDuPmVC+FqMkVbbw
F+WovOFwGxz8N8JRH91BY4OR0a8Gj2U0XzljL1thr+ZjGdMDJ9y33WtDhMB3BxQX
ZpeuP1GtURxslx8zyQX9J0te0tVE3yFvJrvkRi0+4TrnekvuOBUEI7+VBTVj0uTq
IBCaC5SR4o7GehgSbNY3OKHxebAxpnucKZV1Sd+hB1olmEfABNPaaY9b92Y++wQM
CAc8uC1RdVklCQ2dOItDe7AdbNs5TH8C3dgONrivMeJgOmci7JWkupTnYZ98VsLq
ALFl+ptO/7kTNCSa/xWVFERpbR/nvxA0DUwb3GpfQNv7IoHrNvD1v7mrRE6jSvn1
9klxnc9gGeMZ3UMUWx4vd0MjfEWng93b3ryO86Ee/hLSjADTo5faf45XGsBAYMkE
Z3I+hrC8ciHygOjOvbSEGwKAdf18FKUE7xMtna9WJKX18gmnNvSPLE4NG1q1UI4U
/AQ03MnPKoZlC7axZmno3XBnEmFSmLsGjZieEP12gw3+D5U0Dwm+YGNEx7wkX+av
dmYd
=vsM1
-END PGP SIGNATURE-

Re: RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

On Wed, 6 Nov 2024 18:03:07 +
Holger Levsen  wrote:

> On Wed, Nov 06, 2024 at 06:03:45PM +0100, IOhannes m zmölnig wrote:
> > Afaict, the problem is that we have 3 options to pick from, and
> > it's hard for people to decide which is the "right one". I do not
> > see how adding a 4th option will make this decision any easier
> > (esp. since that new option is so similar to an already existing
> > one).  
>  
> absolutly.

I have been thinking about it for a while and I am thinking that adding
a fourth field really is probably not the right way to go. Then again,
given that policy is clear about how Recommends ought to be used and
it's pretty clear that there are packages that just don't use it right,
I don't think an effort to "fix" the use of Recommends across Debian is
going to be terribly helpful because even if it succeeds, people are
probably going to make the same mistakes again. (It's not obvious that a
field called "Recommends" should only be used for not-quite-vital
dependencies, not recommendations in general. The very name of the
field begs for people to misuse it.)

Any suggestions for how to approach the problem as one of awareness
rather than one of technical limitations?

> maybe the problem is also related that the original poster didn't
> know about the diffoscope-minimal package because it's non obvious
> and somewhat hard to find?

My use of diffoscope was more to make a point in general about a
systemic problem (it was the most extreme example I could think of).
However, it is also true that I did not know about diffoscope-minimal,
and had I known about it I probably would have picked some other
package to illustrate the point. For instance, gwenview currently
recommends kamera. gwenview is an image viewer, kamera is a tool for
working with digital cameras. Now it is true that kamera enhances
gwenview's functionality by allowing it to see pictures on a digital
camera that is plugged into the system, but by no means is gwenview
useless or even substantially degraded from a functionality standpoint
when kamera is missing. It ought to be a Suggests according to Debian
policy, but it's obvious why it ended up being a Recommends because it
does enable additional functionality that doesn't work otherwise.

Aaron

> $ apt-cache search minimal|cut -d ' ' -f1|grep minimal$
> cm-super-minimal
> diffoscope-minimal
> gdb-minimal
> haskell-devscripts-minimal
> keepassxc-minimal
> kde-telepathy-minimal
> python3-minimal
> libpython3.12-minimal
> python3.12-minimal
> libpython3.13-minimal
> python3.13-minimal
> virtuoso-minimal
> 
> are there other similar metapackages?
> 
> 



pgpAGJl7tCgTP.pgp
Description: OpenPGP digital signature

Re: RFC: "Recommended bloat", and how to possibly fix ito

[Bill Allombert]

Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit :
> Hello, and thanks for your time.
> 
> I've been a Debian user and contributor for a while, and have noticed a
> rather frustrating issue that I'm interested in potentially
> contributing code to fix. The issue is what I call "Recommended bloat",
> which in short is what happens when you install a package with all of
> its recommended packages, and end up with a whole lot of stuff installed
> that you don't want and that the package you actually wanted probably
> didn't even need.

A proposal I made was an option for apt to handle Recommends non
recursively.
That is if A Recommends B and B Recommends C,
apt-get install A --no-transitive-recommends
would install B but not C.

Cheers,
Bill.

Re: RFC: "Recommended bloat", and how to possibly fix it

[Soren Stoutner]

On Wednesday, November 6, 2024 12:08:07 PM MST Aaron Rainbolt wrote:
>For instance, gwenview currently
> recommends kamera. gwenview is an image viewer, kamera is a tool for
> working with digital cameras. Now it is true that kamera enhances
> gwenview's functionality by allowing it to see pictures on a digital
> camera that is plugged into the system, but by no means is gwenview
> useless or even substantially degraded from a functionality standpoint
> when kamera is missing.

In my opinion, gwenview recomminding kamara is the correct behavior and inline 
with policy.

If I install an app, Recommends should pull in everything that would make all 
the buttons in the GUI work correctly.  I shouldn’t have to manually install 
anything else for them to work.  Kamera should definitely be in Recommends for 
gwenview (although not in depends).

If you don’t want that, set your system to not automatically install 
recommended packages, and then you can manually install whatever you want to 
get all the features of the app to work correctly.  But please don’t mess up 
Recommends working correctly for the rest of us.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: RFC: "Recommended bloat", and how to possibly fix it

[Aaron Rainbolt]

On Wed, 06 Nov 2024 14:21:30 -0700
Soren Stoutner  wrote:

> On Wednesday, November 6, 2024 12:08:07 PM MST Aaron Rainbolt wrote:
> >For instance, gwenview currently
> > recommends kamera. gwenview is an image viewer, kamera is a tool for
> > working with digital cameras. Now it is true that kamera enhances
> > gwenview's functionality by allowing it to see pictures on a digital
> > camera that is plugged into the system, but by no means is gwenview
> > useless or even substantially degraded from a functionality
> > standpoint when kamera is missing.  
> 
> In my opinion, gwenview recomminding kamara is the correct behavior
> and inline with policy.
> 
> If I install an app, Recommends should pull in everything that would
> make all the buttons in the GUI work correctly.  I shouldn’t have to
> manually install anything else for them to work.  Kamera should
> definitely be in Recommends for gwenview (although not in depends).
> 
> If you don’t want that, set your system to not automatically install 
> recommended packages, and then you can manually install whatever you
> want to get all the features of the app to work correctly.  But
> please don’t mess up Recommends working correctly for the rest of us.

And this brings us back to the original idea of creating a Weak-Depends
field. From my viewpoint, policy states that Recommends is for
declaring a strong (heavy emphasis on "strong" here), but not absolute,
dependency. If the lack of kamera made it so that portions of
gwenview's user interface were visibly grayed out, or error messages
were displayed, then I would see it as a strong dependency since the
lack of it results in a substantial degredation of functionality. But
when kamera is missing, gwenview still works. Things that try to access
the `camera:` KIO slave won't work, but that's the extent of the issues
caused. KIO slaves are essentially plugins of sorts, so I see this as
an additional "nice-to-have" that isn't a dependency at all. This
isn't the only example either - I've had live image builds pull in
things that seemed (to me) to be completely "out of left field", like
random terminal emulators that I have neither interest in nor
willingness to keep in my image builds. (I don't know exactly which
package was the culprit there.)

The solution you mention is to not automatically install recommended
packages. But then you run into "fun" edge cases like system boot
failures[1], sudo or user-setup not being installed[2], and things like
that. When a packager needs to say "technically package A can function
without package B, but only if the user knows exactly what they're
doing", Recommends is the only way to express that, and if Recommends
is also being used to ship unnecessary terminal emulators, plugins for
little-used image viewer functionality, and the like, there's no good
solution except for manual fiddling. This is causing real problems in
at least one downstream derivative of Debian (Kicksecure, which I am
working with), which is why I'm hoping to find a good solution that I
can start implementing and sending patches for.

This isn't to disagree with you at all - I agree that gwenview shipping
kamera as a Recommends is a good thing. Like you say, "I shouldn't have
to manually install anything else for [the buttons in the GUI] to
work". That's a perfectly logical thing to use a field called
Recommends for. But if it's going to be used for that, it would be very
beneficial to identify packages that are recommended and important vs.
packages that are recommended but not that important. That's what I was
thinking Weak-Depends, or a solution similar to it, could do. In the
absence of that, demoting kamera to a Suggests would seem more
policy-compliant in my opinion, but then again that's just my opinion.

(Side note, I wonder if there's a way to implement Weak-Depends that
*doesn't* require modifying all of the tons of packages Johannes
mentioned. Maybe some way of annotating packages in Recommends as
"important" would permit a distinction to be made here in such a way
that most tools wouldn't need changes? Those that were updated would be
able to understand the distinction, those that weren't would continue
to treat Recommends the same way they do today. No idea if that's
feasible, just something that went through my head.)

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792
 If systemd-cryptsetup is missing on an encrypted system and one
 installs dracut with --no-install-recommends, the system will be
 rendered unbootable.
[2]: 
https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html
 Section 8.4.3


pgpyd4I9j4qPq.pgp
Description: OpenPGP digital signature

Re: Rebuilds to enable PAC and BTI support on arm64

[Guillem Jover]

Hi!

On Wed, 2024-11-06 at 17:28:38 +0500, Andrey Rakhmatullin wrote:
> On Wed, Nov 06, 2024 at 10:43:07AM +0100, Emanuele Rocca wrote:
> > As a final thought, given that new toolchain versions bring multiple
> > improvements over the years it's perhaps worth thinking about rebuilding
> > the archive on some sort of regular basis to make sure we get the
> > benefits?
> 
> "Let's at least force rebuilds all packages not rebuilt since stable
> before every freeze starts" is a popular opinion.

Of course, as Emanuele mentions doing mass rebuilds, which seems to
be more common nowadays, can bring benefits from toolchain improvements
(potentially all layers from compilers, to packaging tools).

But routinely rebuilding and _uploading_ the results also comes with
its drawbacks. For one it will hide ABI breaks. Having packages not get
upgraded during a Debian release upgrade has also been a good and easy
indicator for end users that those packages are stale and perhaps it's
time to look for alternatives.

Thanks,
Guillem