packages.debian.org APT package repository web interface for deb.whonix.org

Development
21

Could you remove please / prevent creation of the bullseye repository? This is because for bookworm, the packages are properly sorted. Kicksecure packages are only in the Kicksecure repository. And Whonix packages are only in the Whonix repository. That is cleaner and less duplication.
(Previously all repositories had all packages mixed due to split of Kicksecure, Whonix. Legacy.)
Because I don’t want this to be mixed up on search engines.

22

Ok so I am working on redesigning this site, making it performant, and making it better from an HTML SEO standpoint

Can I get a confirmation this is the general structure that is appropriate? We can work on combining suites after the initial rework, since descriptions can be very different. But I think that is a reasonable lift

In the meanwhile:

├── bookworm
    └── package-1-nonfree
    ├── package-1-main
    └── package-2-main
└── bookworm-developers
    └── package-1-nonfree
    ├──  package-1-main
    └── package-2-main

Other notes

  1. Add all the HTML suggestions you posted
  2. Add all the footer stuff you suggested
  3. All software depedencies must be installable via APT
  4. Remove dependency on CI for publishing (this can easily be achieved with hugo)
  5. Do not add bullseye repo
  6. No html suffix
  7. No unnecessary pages with links on them
  8. Performant at scale, with usable search

Please confirm the above when you get a chance @Patrick , no rush. Thank you :slight_smile:

1 Like
23

Excellent!

Please drop the appendix -nonfree etc.

Here is a randomly chosen nonfree package to show how Debian shows the nonfree inside the website itself.

Also please call it non-freedom instead of nonfree as the latter causes confusion for non-native speakers that don’t know the context of free/freedom vs non-free(dom) software, licenses. Implies payment is required which is wrong.

1 Like
24

Okay can we talk about the structure of this? Pretend it is HTML

**Package:** <%= pkg[:package] %>

**Suite:** <%= pkg[:suite] %>

**Version:** <%= pkg[:version] %>

**Architecture(s):**  <%= pkg[:architecture] %>

**Maintainer:**  <%= pkg[:maintainer] %>

**Installed_size:**  <%= pkg[:installed_size] %>

**Recommends:**  <%= pkg[:recommends] %>

**Conficts:**  <%= pkg[:conficts] %>

**Replaces:**  <%= pkg[:replaces] %>

**Provides:**  <%= pkg[:provides] %>

**Homepage:**  [<%= pkg[:homepage] %>](<%= pkg[:homepage] %>)

**Priority:**  <%= pkg[:priority] %>

**Section:** <%= pkg[:section] %>

**Filename:**  <%= pkg[:filename] %>

**Size:**  <%= pkg[:size] %>

**Sha256:**  <%= pkg[:sha256] %>

**Sha1:**  <%= pkg[:sha1] %>

**Md5sum:**  <%= pkg[:md5sum] %>

**Description:** <%= pkg[:description] %>

Clarifying questions…

  1. If a “conflicts” and “recommends” are different for different architectures, how should that look? Other differing data for packages in different architectures?
  2. We want to add something to signifiy on the page if the package is non freedom software?
  3. Do we create separate HTML pages for each suite’s version of a package? i.e. nano for bookworm-developers and nano for bookworm stable?

Parsing the packages is not terribly complicated, but it is not terribly trivial either. We want to parse this in a usable way that makes sense.

1 Like
25

Ignore naming…naming is trivial. Data structure

├── bookworm
    └── package-1
    ├── package-2
    └── package-3
└── bookworm-developers
    └── package-1
    ├──  package-2
    └── package-3

So we have 1 file for all architectures of a package in each suite? No multiple files for separate architectures? We can assume that things like description will be the same, but perhaps data like recommends and conflicts will be different for different architectures?

1 Like
26

Plan for moving forward

  1. Make crude and simple markdown files of how we want the data displayed. Get this approved before moving forward
  2. Add markdown to an HTML generator, that can be served on our servers. Create a bare bones HTML skeleton. Get this approved before moving forward
  3. Implement better HTML for SEO and consistency
  4. Style for UI/UX

Right now, only focusing on step 1. Will ignore rest of the steps until we have a usable iteration of each step.

1 Like
27

Looks nice. Some details:

Since that would show my name all over the place, best avoided to avoid persona cult and everyone asking me directly.

Can drop for brevity.

I am not sure. But it would take years until we reach this kind of complexity.

That would be good. And using it consistently.

  • Freedom Software (green color)
  • Contrib (red? color)
  • non-freedom software (red color)

(Debian show contrib, nonfree but no hint in case of free which I find inconsistent and confusing.)

I guess this is needed. Debian does the same. This is because version numbers, description, dependencies can all be different.

Yes.

Not sure. Maybe could be in theory. But we won’t have this issue for now. Seems like a super detail for the far future.

Good question…

I guess we don’t need 1 file for each architecture.

Example Debian “all” architecture package:

Example Debian “multiple” (not all) architecture package:

Debian lists the available architecture on the 1 page for the 1 suite (bookworm) of the package.
If that works for Debian, that should work for us too.

So please no separate pages for each architecture, that would be spammy.

Sounds all good!