[oi-dev] Purpose of PACKAGE_NAMES
Aurélien Larcher
aurelien.larcher at gmail.com
Sat Sep 30 16:28:40 UTC 2023
On Fri, Sep 29, 2023 at 3:13 PM Marcel Telka <marcel at telka.sk> wrote:
> On Fri, Sep 29, 2023 at 02:13:42PM +0200, Aurélien Larcher wrote:
> > On Fri, Sep 29, 2023 at 10:15 AM Marcel Telka <marcel at telka.sk> wrote:
> >
> > > Hi,
> > >
> > > I noticed there are PACKAGE_NAMES macros set for few components in the
> > > oi-userland git repo. Namely here:
> > >
> > > components/meta-packages/history/Makefile
> > > components/openindiana/gfx-drm/Makefile
> > > components/openindiana/pkg/Makefile
> > > components/openindiana/slim_source/Makefile
> > >
> > > They were added in October 2018 by following commits:
> > >
> > > c7b5e23fc94
> > > 2e3897664af
> > > ac1196a7cb0
> > > a4bb6ce259f
> > >
> > > I'm curious what is the purpose of these macros. As far as I know
> there
> > > is no known consumer for them. They looks like some attempt to list
> > > packages generated by a component before we had support for pkg5 files
> > > (introduced in 2020).
> > >
> > > If PACKAGE_NAMES are unused then I plan to simply remove them once I
> > > touch those Makefiles.
> > >
> >
> > If I remember correctily they were introduced to produce package names
> used
> > in dependency resolution in the external python scripts, for components
> > that generate packages internally and then copy them rather than the
> usual
> > procedure.
>
> Okay, thanks. I translate the above as: yes, PACKAGE_NAMES was a
> predecessor of pkg5.
>
> > The goal was to trigger rebuild of dependencies based on this information
> > and avoid publication of broken repositories e.g. when ABI is broken and
> > the update is split in several PRs due to our flawed CI.
>
> If I'm not mistaken the same could be done using the (modern) pkg5 files.
>
If you see the packages listed in the pkg5 files then it is fine indeed.
We had some work in progress back then with Adam but some parts were never
integrated.
However the pkg5 part did work to the extent that the dependency graph was
built.
Thanks for looking into it.
>
> > Without these definitions print-package-names would produce an incomplete
> > list of packages provided by the component and the graph will have
> dangling
> > dependencies.
>
> I just tried `gmake publish` and then `gmake print-package-names` in
> openindiana/pkg and this is the result:
>
> Makefile:45: warning: overriding recipe for target 'update'
> /data/builds/ul-workspace/make-rules/component.mk:49: warning: ignoring
> old recipe for target 'update'
> package-names= (origin: undefined, flavor: undefined)
>
> So PACKAGE_NAMES is useless there these days.
>
> Also, `gmake update-metadata` in openindiana/pkg does strange things, so
> apparently there is something else broken. Anyway, if `gmake
> update-metadata` is able to work for openindiana/illumos-gate without
> PACKAGE_NAMES, then we should be able to make it working for other
> components too wihout PACKAGE_NAMES.
>
> > However I am not sure if the bass/component.py script still relies on
> these
> > definitions (there is also a build-plan branch that attempts to automate
> > rebuild of dependencies).
>
> I'm unable to find PACKAGE_NAMES in bass/component.py so it apparently
> does not rely on it. And looking at the history it never did.
>
> Quick look at your build-plan branch shows there is no PACKAGE_NAMES
> mentioned there.
>
>
> So the result so far is: PACKAGE_NAMES is unused nad useless and we
> should simply remove it.
>
>
> Thanks Aurélien for information.
>
> --
> +-------------------------------------------+
> | Marcel Telka e-mail: marcel at telka.sk |
> | homepage: http://telka.sk/ |
> +-------------------------------------------+
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>
--
---
Praise the Caffeine embeddings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20230930/61620f1c/attachment.html>
More information about the oi-dev
mailing list