1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Dependencies between components.

    From Tim Woodall@21:1/5 to All on Sat Mar 30 17:00:02 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Woodall@21:1/5 to Simon Hollenbach on Sat Apr 6 18:40:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)