5 ms·

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it wou

by fn-mote 11mo ago

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that the "new solver" currently lacks a testsuite (unit tests; it has integration tests). I'm actually kind of surprised that writing a dependency solver is a greenfield project instead of using an existing one. Or is this just a dig at something that pulls in a well-tested external module for solving? Posted in curiosity, not knowing much about apt.

stonemetal12 11mo ago
Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?
- steveklabnik 11mo ago
  Cargo's solver incorporates concepts that .debs don't have, like Cargo features, and I'm sure that .debs have features that Cargo packages don't have either.
- mikepurvis 11mo ago
  Historically apt hasn't had much of a "solver". It's basically take the user's upgrade/install action, if there's some conflict or versioned requirement, go to the candidate (≈newest barring pinfile shenanigans) of the involved packages, and if there's still a conflict, bail. It was always second-tier utilities like Aptitude that tried to search for a "solution" to conflicting packaging constraints, but this has always been outside of the core functionality, and if you accepted one of Aptitude's proposed paths, you would do so knowing that the next apt dist-upgrade was almost certainly going to hose everything again. I think the idea in Apt-world is that it's the responsibility of the archive maintainer to at all times present a consistent index for which the newest versions of everything can coexist happily together. But this obviously breaks down when multiple archives are active on the same apt conf.
- pornel 11mo ago
  Cargo isn't satisfied with its own solver either. Solvers are a hard and messy problem. The problem is theoretically NP complete (a SAT solver), but even harder than that: users also care about picking solutions that optimize for multiple criteria like minimal changes, more recent versions, minimal duplication (if multiple versions can coexist), all while having easy-to-understand errors when dependencies can't be satisfied, and with better-than-NP performance. It ends up being complex and full of compromises.
  - catlifeonmars 11mo ago
    Go’s solver has been my favorite so far. But it relies on semver actually being meaningful.
- kzrdude 11mo ago
  Uv uses pugrub and maybe APT could too.
catlifeonmars 11mo ago
Dependency solvers are actually an area that can benefit from updating IMO.
inetknght 11mo ago
> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.
- nofunsir 11mo ago
  Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.
  - nerdponx 11mo ago
    As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.
    - nofunsir 11mo ago
      I've got a bridge to sell. It's made from watered-down concrete and comes with blueprints written on site. It was very important to get the implementation started asap to shorten the review cycle.
      - nerdponx 11mo ago
        In a way, bridges are kind of agile. There are many stages of things like site selection, geological testing, architectural and engineering design decisions, computer simulations, traffic forecasting, etc. All of that happens in a feedback loop with the customer (eg some state DOT).
cactusfrog 11mo ago
Could the rust code be transpired to readable C?
- estebank 11mo ago
  > readable No, because some things that are UB in C are not in Rust, and vice versa, so any codegen has to account for that and will result in additional verbosity that you wouldn't see in "native" code.
  - cactusfrog 11mo ago
    Thank you for the explanation
deleted 11mo ago
[deleted]
dontlaugh 11mo ago
It seems silly to say that it has no tests. If I had to pick between unit and integration tests, I'd pick integration tests every time.
- sedatk 11mo ago
  It has integration tests.

by fn-mote 11mo ago

stonemetal12 11mo ago

Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?

steveklabnik 11mo ago
Cargo's solver incorporates concepts that .debs don't have, like Cargo features, and I'm sure that .debs have features that Cargo packages don't have either.
mikepurvis 11mo ago
Historically apt hasn't had much of a "solver". It's basically take the user's upgrade/install action, if there's some conflict or versioned requirement, go to the candidate (≈newest barring pinfile shenanigans) of the involved packages, and if there's still a conflict, bail. It was always second-tier utilities like Aptitude that tried to search for a "solution" to conflicting packaging constraints, but this has always been outside of the core functionality, and if you accepted one of Aptitude's proposed paths, you would do so knowing that the next apt dist-upgrade was almost certainly going to hose everything again. I think the idea in Apt-world is that it's the responsibility of the archive maintainer to at all times present a consistent index for which the newest versions of everything can coexist happily together. But this obviously breaks down when multiple archives are active on the same apt conf.
pornel 11mo ago
Cargo isn't satisfied with its own solver either. Solvers are a hard and messy problem. The problem is theoretically NP complete (a SAT solver), but even harder than that: users also care about picking solutions that optimize for multiple criteria like minimal changes, more recent versions, minimal duplication (if multiple versions can coexist), all while having easy-to-understand errors when dependencies can't be satisfied, and with better-than-NP performance. It ends up being complex and full of compromises.
- catlifeonmars 11mo ago
  Go’s solver has been my favorite so far. But it relies on semver actually being meaningful.
kzrdude 11mo ago
Uv uses pugrub and maybe APT could too.

catlifeonmars 11mo ago

Dependency solvers are actually an area that can benefit from updating IMO.

inetknght 11mo ago

> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.

nofunsir 11mo ago
Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.
- nerdponx 11mo ago
  As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.
  - nofunsir 11mo ago
    I've got a bridge to sell. It's made from watered-down concrete and comes with blueprints written on site. It was very important to get the implementation started asap to shorten the review cycle.
    - nerdponx 11mo ago
      In a way, bridges are kind of agile. There are many stages of things like site selection, geological testing, architectural and engineering design decisions, computer simulations, traffic forecasting, etc. All of that happens in a feedback loop with the customer (eg some state DOT).

cactusfrog 11mo ago

Could the rust code be transpired to readable C?

estebank 11mo ago
> readable No, because some things that are UB in C are not in Rust, and vice versa, so any codegen has to account for that and will result in additional verbosity that you wouldn't see in "native" code.
- cactusfrog 11mo ago
  Thank you for the explanation

deleted 11mo ago

[deleted]

dontlaugh 11mo ago

It seems silly to say that it has no tests. If I had to pick between unit and integration tests, I'd pick integration tests every time.

sedatk 11mo ago
It has integration tests.