tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg-config difference when run in pkgsrc vs normal run?



Andrew Randrianasulu <randrianasulu%gmail.com@localhost> writes:

> I wonder when I should enable additional architectures for testing? Before
> package enters (hopefully) main pkgsrc tree or after?

I don't follow "enable".  Generally, a package should run on any
architecture and if not it's a bug.  If it's known not to run on some
system, then BROKEN_ON for that system, written narrowly to only include
what is known to fail, is ok.

ONLY_FOR/NOT_FOR is very limited.  It's only when there is an
architectural reason why the package does not make sense on that system.
The standard example is that if an OS has an unusual kernel feature, and
the point of the package is to be userland control for that feature.

A package where upstream has a nonportable implementation and lacks
support for a system is tagged as BROKEN_ON, if it would be conceptually
reasonable for upstream to extend support.  (Or, implement in such a way
that it relies on POSIX and does not need per-OS support.)

It is never ok to limit to systems that have been tested.

It is reasonable to have a test item in TODO, with notes where it has
been verified to work.


Home | Main Index | Thread Index | Old Index