[haiku-bugs] Re: [Haiku] #12917: get_package_dependencies needs to be refactored
- From: "kallisti5" <trac@xxxxxxxxxxxx>
- Date: Sat, 20 Aug 2016 20:21:57 -0000
#12917: get_package_dependencies needs to be refactored
--------------------------------+----------------------------
Reporter: kallisti5 | Owner: kallisti5
Type: enhancement | Status: new
Priority: normal | Milestone: Unscheduled
Component: Kits/Package Kit | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------------+----------------------------
Comment (by kallisti5):
Replying to [comment:5 bonefish]:
Replying to [comment:4 kallisti5]:
Replying to [comment:3 bonefish]:
Replying to [ticket:12917 kallisti5]:
The requirements of get_package_dependencies could be greatly
cleaned up.
Which requirements?
The requirement for the repo.info and repo to know where they will
exist ahead of time... it's ridiculous to have a package repository "need
to know" where it will exist ahead of time... no other repo has this
requirement *AND* the url in repo.info / repo is '''only''' used for
get_package_dependencies.
Again, you've got it the wrong way around: get_package_dependencies
needs a URL for the package downloads. It was conveniently already
available in the repository file, which is needed for dependencies
resolution anyway. If the URL hadn't been in the repository file, it would
have been passed as an additional parameter.
I definitely get the convenience factor after taking a few passes at
solving the issue :-).
My largest push for removing the url is to solve some of the "death by
1000 paper cuts". I've noticed a trend over the last two years of anyone
working on package management repos + auto building getting burnt out
pretty quickly. No-one can nail down any single issue, but the large
number of steps and complex requirements seem to be of some cause.
Anything we can simplify might make it easier on folks and upkeep easier.
As for the mirror scenario... lets just use a UUID or something in
repo.info plus a last updated timestamp in repo.
I don't quite see the advantage, but feel free to change that.
Mostly to make repository tracking based on a random identifier vs a
specific url. Repositories should be portable. Tracking URL's as unique
identifiers can become a bit odd if the repo doesn't live at a specified
url anymore... uuid's per are a bit less confusing.
If we paired a UUID and a timestamp with some text "mirrors" file in the
repository, someday the Package Kit could store + offer users multiple
mirrors and check how fresh they are while tracking them regardless of
url.
**Current Behaviour**
get_package_dependencies takes in the following arguments:
* Several binary local repo files which contain the url, and
repo package inventory
* These are pretty much http://packages.haiku-
os.org/haikuports/master/repo/x86_64/current/repo generated from
http://packages.haiku-
os.org/haikuports/master/repo/x86_64/current/repo.info.
No, they are not the "current" repositories. You need to understand
that the Haiku git repository '''defines''' the HaikuPorts package
repositories. This provides us with the ability to build an old Haiku
revision with the same packages repositories they matched originally. If
you start building against the "current" repositories, you'll lose this
build stability.
There have been multiple people commenting on how much of a pain it
requiring code updates to Haiku any time a HaikuPorts package is updated.
We have pretty advanced versioning schematics in the package definitions
already... lets put them to good use.
Maybe you could give some details on what you have in mind, because ATM
I don't see a solution that could possibly work.
No clue. :-)
This all isn't any kind of attack.. our existing package kit and
repository code is an amazing accomplishment. I'm just trying to find a
way to shave off a few pointy bits that keep poking at people :P
--
Ticket URL: <
https://dev.haiku-os.org/ticket/12917#comment:6>
Haiku <
https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
