[haiku-bugs] Re: [Haiku] #14927: HaikuDepot doesn't show any packages
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Mon, 18 Nov 2019 09:34:48 -0000
#14927: HaikuDepot doesn't show any packages
---------------------------------------+----------------------------
Reporter: KapiX | Owner: apl-haiku
Type: bug | Status: reopened
Priority: normal | Milestone: Unscheduled
Component: Applications/HaikuDepot | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
---------------------------------------+----------------------------
Comment (by pulkomandy):
2 Is it likely that the URL currently used as identifier at least for
HaikuPorts and Haiku will ever change again?
I hope not, but I am not too sure; Alex would be best placed to answer
this question. I hope not!
That's the point of an identifier, and that is what 'url' is, despite the
confusing name.
... What was rejected is breaking the repository format, and
preventing seamless upgrades. ...
If an "identifier" with a UUID were added into the "repo.info" file in
the repository then the HPKR update operation could be amended to update
the "identifier" when it refreshes if it is missing locally. After 6-12
months it would probably be possible to make this change without impacting
too many people. It would be some work to achieve this.
What would an UUID rather than an URI bring us here? I find the URI more
generic. In fact, if someone were to create a new repo they could very
well use "uuid:7673868d-231e-490d-9c4f-19288e7e668d" as the URL (it's
technically an URI, not URL, but we already agree the current naming is
confusing). Using an https URL here is a bit more descriptive (we also use
it as an user-visible identifier for the repo, so an HTTP URL is more
readable than an UUID).
The idea is to identify a resource here (namely, the repository), and
that's what URI are for.
Unlike URLs, they only identify, but don't always allow to locate the
resource. A typical example is, you can use isbn: URIs to identify books
by their barcode. This does not tell you where the book is available, but
it allows you to uniquely identify the book.
... This has, however, no impact on how we name things ...
Previous to this change, it was very confusing having multiple uses for
the term "url" and also different terms for this conceptual "identifier".
At the moment the term "url" is consistent in the HDS database, the HDS
source, the HDS API signatures, the HD source, the package library and
through the {{{repo.info}}} file. Somebody can trace it from start to
finish by name and that is of significant value for maintenance. It was
quite a bit of work to achieve that so I would be averse to renaming
anything without ensuring follow-through to ensure the work were done
consistently across both data and software.
Yes, of course, but the name is still a bit confusing. We could rename
"url" to "identifier" or "uri" or something like that in all the code and
documentation, and add a note that in the HPKR file format, it is stored
as "url" for legacy reasons. Or we can introduce a new version of HPKR
files that uses the new name instead.
However, what I would prefer to avoid is having both "url" and
"identifier" or "uri" live side by side in the HPKR file, as this would
further confuse things.
So:
* +1 to renaming "url" in the code, I don't know if it's worth introducing
a new version of HPKR files or if we can live with keeping "url" just
there
* +1 to using an "uuid:" or other non-http scheme for the identifier to
reduce risk of confusion, but only for new repos. For the existing ones,
keeping the existing identifiers is probably less problematic (unless we
do some special-casing to handle the migration? is it worth the effort?)
* -1 to hardcoding the identifier to be an UUID, as I don't like that they
are not helpful to the end-user, and they are a less flexible solution
than using an uri (which can then effectively be used with an uuid: URI,
but gvies us more flexibility if we want to use something else)
--
Ticket URL: <
https://dev.haiku-os.org/ticket/14927#comment:14>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
