cvs commit: ports/print/acroread7 Makefile

[Alexander Leidinger]

On Fri, 7 Oct 2005 19:05:15 -0400 (EDT)
Trevor Johnson <trevor at jpj.net> wrote:

> > >  Remove unneeded USE_LINUX=yes and USE_XLIB=yes, and an erroneous
> > >  comment about the need to run brandelf, which were added by netchild.
> >
> > Acroread depends upon files which come with linux_base-X. USE_LINUX=yes adds
> > a dependency to it (if you don't use the default linux base you have to set
> > OVERRIDE_LINUX_BASE=foo in make.conf for this to work correctly). It also
> > uses the X11 libs, so USE_XLIB (or USE_X_PREFIX, but see below) is needed,
> > else the dependency list is not correct and people which install acroread as
> > the only linux program don't get the X11 libs (for the default linux base).
> 
> The dependencies are there, as you will see if you install the port and
> look at its /var/db/pkg/acroread7-7.0.1/+CONTENTS file.  The dependency on
> linux-gtk2 brings in dependencies on linux_base and the Linux X libraries.

Yes, an implicit dependency. I'm not very excited about an implicit
dependency if a port depends upon this dependency directly. And
Acroread depends upon it directly.

An implicit dependency (let's call it port A) makes it "a little bit
harder" for someone who changes port A in a way which results in the
need to change all ports which depend upon it.

> > For a non-default linux base this isn't needed since you decided to include
> > the X11 libs into some linux_base-X ports, but the official linux base port
> > has to be the reference. USE_LINUX=yes also changes some defaults e.g. STRIP
> > and more.
> 
> The use of strip isn't something I had thought about at all.  To follow
> the licence, we mustn't run strip.  I will check into whether it's being
> run.

The point is: USE_LINUX implies some magic behind the scenes which
every linux port needs (more or less). So the current behavior is to
not strib executables when installed by install(1). If you don't use
install(1), it may not affect you (because it implies a brandelf to
FreeBSD), and if you use install(1), you will get what you want (but
only if you use USE_LINUX=yes). It also sets STRIP_CMD to the right
value (either true if the linux strip isn't available, or the linux
strip command). USE_LINUX also implies NO_FILTER_SHLIBS.

You can do all this on your own, but it would defeat the purpose of the
ports collection (and USE_LINUX).

As a general rule we can say: every linux port should use USE_LINUX.
The only exceptions are:
 - in linux_base*
 - where the use of USE_LINUX breaks the port

Both exceptions aren't met in acroread7 so far. 

> > Technically it isn't needed to run brandelf, but to be on the safe side we
> > should use it. There are cases where you can shoot into your foot without a
> > branded binary. I didn't encountered such an edge case myself, but I
> > remember a case where an unbranded binary caused the system to reboot
> > (because it triggered the wrong syscall). Feel free to start a discussion
> > about the necessarity/deprecation of brandelf on -current if you think
> > brandelf is useless.
> 
> Unfortunately, as hrs pointed out to me, the licence for this program
> forbids us from changing its contents.  I don't think that brandelf is, in
> general, useless, but fortunately it is not needed for this particular
> port:
> 
> $ file
> /usr/local/lib/acroread/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread
> /usr/local/lib/acroread/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread:
> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux
                                                     ^^^^
% file /compat/linux/sbin/ldconfig
/compat/linux/sbin/ldconfig: ELF 32-bit LSB executable, Intel 80386,
version 1 (GNU/Linux), for GNU/Linux 2.2.5, statically linked, stripped
           ^^^^^^^^^

That's the part which brandelf changes. So strictly speaking it's
needed. It may be the case that someone can shoot into his foot without
the brandelf. But the license issue is reason enough to not brandelf
anything. But please add a comment (maybe somewhere in/between do-*)
into the makefile why the brandelf isn't done.

> 2.2.5, dynamically linked (uses shared libs), stripped
> 
> > So in short: please add the necessary brandelf part to have a port which not
> > only works, but to have a port which may also play nice in edge cases.
> >
> > >  Also remove his comments about the prefix being wrong.  I am changing
> > >  the prefix.  I think that rather than inserting such comments in a
> > >  port, it is better to contact the maintainer.
> >
> > I did. Several times. Some of the mails where CCed to portmgr (since I don't
> > want to stomp on someone elses feets; I want to see nice progress in the
> > ports collection). Some of the replies where CCed to emulation at . So far I
> > got zero answers from you to every mail I send to you this year. This is sad
> > (for everyone except me), since I describe some fixes/improvements for some
> > of your linux ports which other people don't get ATM.
> 
> The way it looks to me, you did contact me about several of these things,
> but only after adding your comments to the port.  Perhaps I am wrong and I
> overlooked an earlier e-mail from you.

I've mailed the patchset (or at least the URL to it) several times (at
least 2 times I think, maybe more) to each maintainer before I
committed the large changeset.

> > >  Install under LOCALBASE, rather than LINUXBASE, without registering
> >
> > I know there are several people which think LOCALBASE is the right one. The
> > current default policy is to install ports which depend upon X11 into
> > X11BASE. For those which want to object here, please go out and read the
> > previous discussion about this topic, so far there's no resolution to this
> > and portmgr thinks no side was able to provide enough points to come to a
> > conclusion. The defacto standard ATM is to install such ports into X11BASE
> > and acroread should comply IMHO.
> 
> According to hier(7), X11R6 is for the X11R6 distribution (bits from e.g.
> x.org).   I know that many, many ports, including my own, don't comply
> with this.

There are several people which interpret this differently. Please have
a look at the corresponding discussion in ports at . I don't have a URL at
hand ATM... maybe one of the fellow readers can hand it out quickly?

> > As long as acroread (an application which an ordinary user wants to use)
> > stays out of LINUXBASE (the place where the infrastructure for linux
> > applications is installed) I don't moan about using LOCALBASE.
> >
> > So in short: thank you.
> >
> > While I have a look at the acroread7 port: there was a discussion on ports@ a
> > while ago where most ports developers agreed that a port should come with a
> > plist instead of generating the plist from scratch at install time.
> 
> I missed out on this discussion, but I usually like to avoid pkg-plist
> files.  It is part of my personal style and it is technically sound.

The discussion starts at:
  http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019974.html

The initial question is about switching from plist files to
autogeneration, but it's not a lot of work to do a plist file for the
linux ports. I just did it in the morning for linux_base-8 and it was
done in a minute.

And there are already some tools which assist in generating the plist
file.

> > Exceptions are allowed of course, but they are limited to e.g. ports with
> > complex options which change the plist in a non-trivial way. So please add a
> > commit-time plist please. The linux-gtk port already has infrastructure to
> > generate a rough plist from a rpm which just needs to be refined (e.g.
> > removing man-pages and default directories) a little bit.
> 
> A few lines of script in one makefile, versus 8 pkg-plist files--more once
> the slave ports submitted by chinsan have been added--each with around 300
> lines?  I'll take the former, thanks.

Please have a look at the discussion.

> > Another suggestion is to remove the kldstat check in do-build. I can't see a
> > call to a linux binary at compile or install time (I haven't tested this,
> > this is only based upon reading the Makefile, so feel free to prove me
> > wrong). You only need it at run time of acroread7, but it is not the
> > responsibility of each linux port to check for the linux support in the
> > kernel (the linux base does this already, so it's another point for readding
> > the USE_LINUX knob).
> 
> In theory that check should not be needed, but several users sent e-mails
> indicating that they were having problems of this sort.  After joerg added
> the check, the e-mails stopped.  I was thinking of removing the check, but
> then I remembered those e-mails. :-)

That's kind of strange, don't you think? It should be covered by
linux_base (at least the default linux_base has such code (from you?)
already) and without linux_base acroread isn't installed. Any ideas
what could be the cause of this?

Bye,
Alexander.

-- 

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7