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:

> сб, 6 июл. 2024 г., 15:57 Greg Troxel <gdt%lexort.com@localhost>:
>
>> 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.
>
> I do not have many systems, definitely not AIX or Solaris, or much of
> non-x86 ....

I think we are not understanding each other.

I am trying to say that if you have a package, and you have never run it
on AIX, then agreed that you have no idea that if you tried, it would
build or work.  That's ok.

It is not ok to mark it BROKEN_ON+=AIX with reason "I haven't tried it
and it might not work".

Right now you have ONLY_FOR_PLATFORM to NetBSD and two CPU types and no
justification.

> We use somewhat strange feature when number of png files concatenated
> together and put as .o object in final executable. This is ... not very
> portable (I was unable to make it works on macos x) and we also use /proc
> filesystem (so OpenBSD probably out).

OK, but what you are describing are basically upstream ("we" means that
is you I guess) bugs.

> Also, right now env. variable BSD=1 (this signals to our build system to
> omit few features related to signals and thread debugging) is not
> conditional in Makefile. (hopefully easy to fix, but again, I do not have
> working pkgsrc outside of single VM.)

This is what autoconf is for :-) But I would suggest that you first make
the program work on NetBSD, not with pkgsrc.  I always say to people
when a package does not work: if you follow the upstream build
instructions by hand, do you get a working program?  If so, then there
is a pkgsrc bug.  If not, then there is an upstream bug.

That said, pkgsrc does work around upstream bugs.  But, that is working
around, not Plan A.

> Well, as I said source builds for me on Linux/ppc but does not start. So, I
> completely rely on non-automatic reports in this area ...

I do not understand that.


> Just to clarify, you think I should remove ONLY_FOR_PLATFORM= line from
> Makefile, let autobuilders do their thing, then re-add BROKEN_ON based on
> result? Where I can see list of platforms where autobuild fails for my
> specific package? Should I somewhat manually trigger builds on server(s)
> somewhere?

Yes, you should remove it.  But there is no autobuild on wip.

Stepping back:

  are you the upstream?  If so, I think you should fix the upstream
  package to straightforwardly build and work as portably as possible on
  as many systems as possible, by avoiding non-portable things.   And
  then it will be easy to package.
  


Home | Main Index | Thread Index | Old Index