feat: add convience targets

[thesayyn]

Currently targets generated by apt is really crude, forces all packages to be enumerated again in the BUILD file.

This PR improves the API surface by introducing a few new convenience targets.

• @bullseye//:bullseye target at the external repository root which has the same name as the repo that contains all the installed packages + a dpkg_status target for all installed packages to be found by scanners.
• @bullseye//bash target that is alias to architecture specific packages with a select to allow same oci_image target to be transitioned to different platforms.
• @bullseye//:packages target: to access all package archives (including transitives)
• @bullseye//:dpkg_status target: to access a dpkg_status archive (including transitives)

[thesayyn]

cc @jjmaestro

[jjmaestro]

@thesayyn so, part of this is a big chunk of "the top of the stack" of PRs (#100)... and again, given the amount of changes that this will introduce, I will have to re-do a ton of the intermediate PRs in the stack that have been 2 months waiting to be reviewed.

Just FYI, it's very demotivating to see a big chunk of the functionality that made me revamp the repo being implemented without the rest of the changes. And again, this IMHO "slaps it in" while I built the refactor to clean all of the parts. Again, "2 months in the making".

[jjmaestro]

Just more context of how I would have done something like this... at the very least, you could have eyeballed the stack and considered if you are (mostly) going to merge it in or not. And if so, you would have implemented this on top of #100, adding the extra convenience aliases that you are adding.

That would help a contributor like me to feel like the work that's been done is worth something. Instead, I now have to scramble and rebase everything with larger conflicts.

[thesayyn]

I didn't see you made a similar improvement. apologies on my end for that. Big PRs are hard to review and i don't have the time to look at them at once. In my defense refactor PRs are mostly "i don't like the way you did things so i am gonna just change it". I am not trying to be extra, if you look at this you will see that i took the time to actually review and land a lot of PRs.

And the reason pinged you was to get your opinions as you were trying to make this ruleset better. :)

[thesayyn]

It's also fair to mention that i am not getting paid or being thanked either for the most of the work i do here.

[jjmaestro]

IMO refactoring is definitely not "I don't like how you did this". Most of the time it should be to make the code more maintainable so that other changes become easier. That's how I've tried to make all the changes in the stack.

[jjmaestro]

It's also fair to mention that i am not getting paid or being thanked either for the most of the work i do here.

I know, neither are any of the contributors! But that's also why I go above and beyond and document the PRs, what they do, each commit has a (hopefully) clear message and concrete change, etc. So that, regardless of how large the PR / stack, it's easy to see the "conducting thread" and have a breadcrumb / trail of everything.

And that's why it's disconcerting to see that after 2 months, the reviews (which are good, I'm thankful for that) don't look at the whole stack.

Anyway, enough drama. For my part, sorry for dumping this on you.

Will go over the changes over this week and will try to get the PRs in the stack rebased.

[jjmaestro]

Reviewing the PR, and acknowledging I'm very biased because of the outstanding PRs I have done... it definitely looks like this could be implemented easily / easier and IMO nicer on top of #100 😕 It's basically #100 plus some aliases that are quite useful and a very nice approach to generate the Starlark code (VS my crappier ad-hoc approach).

It's probably much to ask but I would appreciate if we could re-do this on top of #100, taking all the cleanups for the lockfile and deb_import. I really like the starlark_codegen_utils.bzl part, I think it would clean up a lot of the code I wrote in deb_import to do the templates.

I'll probably try to re-implement this on top of #100 to see how it looks like, I would really like to try and have it all on the PR stack to avoid more churn (it's taken me days to re-do the PRs 😞 )

[jjmaestro]

Tthe tests are failing in 7.3.1 and 8.0.0rc1.

Here's the patch to fix 7.3.1:

diff --git a/apt/private/BUILD.bazel b/apt/private/BUILD.bazel
index 19a4af1..cadebf9 100644
--- a/apt/private/BUILD.bazel
+++ b/apt/private/BUILD.bazel
@@ -27,6 +27,8 @@ bzl_library(
     visibility = ["//apt:__subpackages__"],
     deps = [
         ":lockfile",
+        ":starlark_codegen_utils",
+        "@bazel_skylib//lib:new_sets",
         "@bazel_tools//tools/build_defs/repo:cache.bzl",
         "@bazel_tools//tools/build_defs/repo:http.bzl",
         "@bazel_tools//tools/build_defs/repo:utils.bzl",
@@ -95,3 +97,9 @@ bzl_library(
     visibility = ["//apt:__subpackages__"],
     deps = [":version"],
 )
+
+bzl_library(
+    name = "starlark_codegen_utils",
+    srcs = ["starlark_codegen_utils.bzl"],
+    visibility = ["//apt:__subpackages__"],
+)

[jjmaestro]

Also found a bug that breaks in amd64, here's the fix:

diff --git a/apt/private/deb_translate_lock.bzl b/apt/private/deb_translate_lock.bzl
index 6491868..509062c 100644
--- a/apt/private/deb_translate_lock.bzl
+++ b/apt/private/deb_translate_lock.bzl
@@ -169,11 +169,11 @@ def _deb_translate_lock_impl(rctx):
             _PACKAGE_TEMPLATE.format(
                 target_name = package["name"],
                 data_targets = starlark_codegen_utils.to_dict_attr({
-                    "//:linux_%s" % arch: "//%s/%s" % (package["name"], package["arch"])
+                    "//:linux_%s" % arch: "//%s/%s" % (package["name"], arch)
                     for arch in architectures._values
                 }),
                 control_targets = starlark_codegen_utils.to_dict_attr({
-                    "//:linux_%s" % arch: "//%s/%s:control" % (package["name"], package["arch"])
+                    "//:linux_%s" % arch: "//%s/%s:control" % (package["name"], arch)
                     for arch in architectures._values
                 }),
             ),

[thesayyn]

Also found a bug that breaks in amd64, here's the fix:

Aha, thank you. one strong reason to not change things because it feels better :)