David Shao <davshao%gmail.com@localhost> writes:
> I would like to have the line
>
> CONFIGURE_ARGS+= --with-pciids-path=${PREFIX}/share/pciids
>
> added to the Makefile for libpciaccess, but I would like libpciaccess
> to only care that misc/pciids is installed and not update as a
> dependency when pciids is updated with say:
>
> pkg_rolling-replace -suv
Generally, -s is not needed; it forces a rebuild even if the package
version has not changed. However, pciids should get a new version
every time it changes, so pkg_rr with or without -s should behave the
same way.
We need to be careful, because the point of the rebuild rules (pkg_rr
and bulk builds) is that one ends up in the same state as if doing a
full build from nothing. It's not clear if what you want is consistent
with that.
> libpciaccess would only care that the file pci.ids is in the directory
> /usr/pkg/share/pciids/ and not what the contents of that file are for
> updating purposes.
I think what you mean is that you would like to split the notion of ABI
(more broadly, run-time interface) into two parts:
a definition of what is logically a procedure call
data returned by that procedure call
and then:
make pcciids only update the first notion of ABI
teach pkg_rr and bulk builds that only a change in the first notion of
ABI triggers a rebuild
This is a lot of work, and the real gain is in marking packages that
have bug fixes but not an ABI change and not an API change in such a way
that they don't have new version numbers. Not only is this tricky to
get right, but it introduces the chance of not getting the right answer
because there was a real change that wasn't noted.
> The file pci.ids is updated frequently, and it would be extremely
> painful to update every single port depending on libpciaccess every
> time pci.ids is updated.
Is it really? Have you tried, and how long does it take? Using bulk
builds, or pkg_rr?
hal is the only dependency.
Why are you using "-s" on pkg_rolling-replace? You are asking for
behavior which is less strict than normal about dependency updates, but
are using an option that causes more strict than normal behavior.
I never use -s unless I have a problem, and then I view the situation as
due to a bug.
But, I think bulk builds are going to be harder, because there the
focus on getting repeatable answers is stronger.
I'm opposed to baking in pciids data to other packages, unless it also
affects the version number, because then you'll have two packages with
the same version and different contents.
I am also not following how pci.ids gets changed frequently. The pkgsrc
entry refers to a specific file with a 2009 date. My package was last
updated in June (not sure why), and doesn't seem to be out of date.
Where are these frequent updates coming from, and how are they
manifesting themselves in pkgsrc?
I agree with jperkin@ that choosing to update the pciids package just
before each branch (eg. on 9/1) makes sense as a workaround for less
than optimal dependency management.
Attachment:
pgpVdtOFEjxeU.pgp
Description: PGP signature