Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #268640 > unrolled thread

Dependencies between components.

Started byTim Woodall <debianuser@woodall.me.uk>
First post2024-03-30 17:00 +0100
Last post2024-04-06 18:40 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  Dependencies between components. Tim Woodall <debianuser@woodall.me.uk> - 2024-03-30 17:00 +0100
    Re: Dependencies between components. Max Nikulin <manikulin@gmail.com> - 2024-03-31 05:00 +0200
    Re: Dependencies between components. Simon Hollenbach <ionpowered@gmail.com> - 2024-04-06 11:00 +0200
    Re: Dependencies between components. Tim Woodall <debianuser@woodall.me.uk> - 2024-04-06 18:40 +0200

#268640 — Dependencies between components.

FromTim Woodall <debianuser@woodall.me.uk>
Date2024-03-30 17:00 +0100
SubjectDependencies between components.
Message-ID<InJhE-2MEZ-7@gated-at.bofh.it>
Is there a wiki or something else that lays out exactly what other
distributions and components each debian (distribution,component) tuple
is allowed to depend on?

This is what I've concluded so far.

I'm assuming transitive dependencies are allowed, e.g.
bookworm-updates-contrib can depend on bookworm-non-free so I've
considered the dependencies between distributions with the same
component and the dependencies between components of the same
distribution separately.


First considering the distribution dependencies. All of these are
always allowed between the same component.

bookworm-proposed-updates : bookworm
bookworm-updates          : bookworm
bookworm-backports-sloppy : bookworm-backports bookworm
bookworm-backports        : bookworm

I believe that updates is a subset of proposed-updates so dependency
on updates by proposed-updates is moot

I'm unclear whether backports is allowed to depend on -updates but I
assume not as I've not seen anything saying that you need to enable
-updates if you enable -backports. I guess the backporter would have to
wait for the point release if they ever needed something only in
bookworm-updates (it's hard to imagine many cases where a -updates
package would be required for backporting so this is somewhat
theoretical - I think it's only if there's a security update involved)


Now considering the dependencies between components in the same
distribution:

contrib                      : non-free non-free-firmware main
non-free                     : non-free-firmware main
non-free-firmware            : main

Some sources seem to say that non-free depends on contrib while others
say contrib depends on non-free. My understanding on contrib is that it
is for packages that cannot be in main because they depend on non-free
even though they're otherwise free. But I'm not sure if there's a two
way dependency here.

I'm assuming that non-free-firmware cannot depend on non-free or contrib
- that would seem to defeat the goal of non-free-firmware - although I
could see a case where a firmware loader is in contrib while the
firmware itself is in non-free so I'm not sure exactly what is allowed
or expected here.

[toc] | [next] | [standalone]


#268656

FromMax Nikulin <manikulin@gmail.com>
Date2024-03-31 05:00 +0200
Message-ID<InTAl-2VOu-1@gated-at.bofh.it>
In reply to#268640
On 30/03/2024 22:54, Tim Woodall wrote:
> I'm unclear whether backports is allowed to depend on -updates

You have not mentioned bookworm-security.

> contrib                      : non-free non-free-firmware main
> non-free                     : non-free-firmware main
> non-free-firmware            : main

https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas
2.2. Archive areas in Debian Policy Manual

[toc] | [prev] | [next] | [standalone]


#268759

FromSimon Hollenbach <ionpowered@gmail.com>
Date2024-04-06 11:00 +0200
Message-ID<Iqa41-4pl1-13@gated-at.bofh.it>
In reply to#268640
Hi,

I have not found a mistake in your considerations about "sane"
component inter-dependency.

However, package dependencies are declared upon a package with a
suitable version, whether this package can be set-up on a bespoke
target system remains to be determined by APT when the package is
installed or upgraded. Just consider for example some manually held
packages - These might break your package install even if all the
needed packages are downloadable (All the components needed are
correctly configured in sources.list ).

I hope this helps. I'd like to understand why you are asking this
question, this might enable us to give you better-suited information.

Ciao,
Simon

P.S.: I am sorry for first sending this to Tim directly - I should
take extra care when using this weird web interface here.

On Sat, 30 Mar 2024 at 18:12, Tim Woodall <debianuser@woodall.me.uk> wrote:
>
> Is there a wiki or something else that lays out exactly what other
> distributions and components each debian (distribution,component) tuple
> is allowed to depend on?
>
> This is what I've concluded so far.
>
> I'm assuming transitive dependencies are allowed, e.g.
> bookworm-updates-contrib can depend on bookworm-non-free so I've
> considered the dependencies between distributions with the same
> component and the dependencies between components of the same
> distribution separately.
>
>
> First considering the distribution dependencies. All of these are
> always allowed between the same component.
>
> bookworm-proposed-updates : bookworm
> bookworm-updates          : bookworm
> bookworm-backports-sloppy : bookworm-backports bookworm
> bookworm-backports        : bookworm
>
> I believe that updates is a subset of proposed-updates so dependency
> on updates by proposed-updates is moot
>
> I'm unclear whether backports is allowed to depend on -updates but I
> assume not as I've not seen anything saying that you need to enable
> -updates if you enable -backports. I guess the backporter would have to
> wait for the point release if they ever needed something only in
> bookworm-updates (it's hard to imagine many cases where a -updates
> package would be required for backporting so this is somewhat
> theoretical - I think it's only if there's a security update involved)
>
>
> Now considering the dependencies between components in the same
> distribution:
>
> contrib                      : non-free non-free-firmware main
> non-free                     : non-free-firmware main
> non-free-firmware            : main
>
> Some sources seem to say that non-free depends on contrib while others
> say contrib depends on non-free. My understanding on contrib is that it
> is for packages that cannot be in main because they depend on non-free
> even though they're otherwise free. But I'm not sure if there's a two
> way dependency here.
>
> I'm assuming that non-free-firmware cannot depend on non-free or contrib
> - that would seem to defeat the goal of non-free-firmware - although I
> could see a case where a firmware loader is in contrib while the
> firmware itself is in non-free so I'm not sure exactly what is allowed
> or expected here.
>

[toc] | [prev] | [next] | [standalone]


#268765

FromTim Woodall <debianuser@woodall.me.uk>
Date2024-04-06 18:40 +0200
Message-ID<Iqhfb-4tQv-3@gated-at.bofh.it>
In reply to#268640
On Sat, 6 Apr 2024, Simon Hollenbach wrote:

> Hi,
>
> I have not found a mistake in your considerations about "sane"
> component inter-dependency.
>
> However, package dependencies are declared upon a package with a
> suitable version, whether this package can be set-up on a bespoke
> target system remains to be determined by APT when the package is
> installed or upgraded. Just consider for example some manually held
> packages - These might break your package install even if all the
> needed packages are downloadable (All the components needed are
> correctly configured in sources.list ).
>
> I hope this helps. I'd like to understand why you are asking this
> question, this might enable us to give you better-suited information.
>

I have local packages I can install that setup sources.list.d so if, for
example, I want to use backports, I can do:
apt-get install bookworm-backports-main-sources
and I will get an appropriate file in sources.list.d. These get
autogenerated.

To cut a long story short, I was missing having backports installed
despite me having a patched version of a backports package installed. I
then missed a security fix because although my tooling saw it and
auto-rebuilt my patched local package, it couldn't install because of
missing (new) dependencies on other packages in backports. The previous
version had installed because it didn't have dependencies on other
packages in backports.

So my local packages that add files to sources.list.d now express
required dependencies - so if I have
bookworm-backports-local-main-sources installed
(which has any packages from backports that I have local changes to) I
will automatically get bookworm-backports-main-sources too.

I've never actually patched any packages from
backports-sloppy/updates/proposed-updates but while I was at it
I thought it made sense to add dependencies for those too so if I ever
do use backports-sloppy, I will get backports too rather than have to
remember to manually install it.

Tim.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web