conflicting dependency
Let's say there are two ports A & B. They both provide libfoo.so.1 (and so register CONFLICTS with each other). Now port C wants to use libfoo (and doesn't care if it gets it from A or B). What does port C list in it's LIB_DEPENDS? What if it lists A and someone installs B... does A get registered as the dependency when C is installed even though A is not installed? This must have been solved already... I just don't see where. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: conflicting dependency
Chuck Swiger wrote at 09:39 -0400 on Jul 20, 2006: > John E Hein wrote: > > Let's say there are two ports A & B. > > They both provide libfoo.so.1 (and so register CONFLICTS with each other). > > > > Now port C wants to use libfoo (and doesn't care if it gets it > > from A or B). > > > > What does port C list in it's LIB_DEPENDS? > > Whichever one the author of port C chooses. > > Quite often, at least for things like the BerkeleyDB, the author of port C > will provide tunable OPTIONS or WITH_ or WITHOUT_ flags that you as the user > of the port can tune to choose a particular version that you like. Just for purposes of clarification, in this example, for purposes of what C wants libfoo for, either libfoo from A or B will do. C doesn't care. > > What if it lists A and someone installs B... does A get registered as > > the dependency when C is installed even though A is not installed? > > No, the port should be registered against B and not A, if B is installed. I agree. It should. But how does the ports infrastructure accomplish that? If the porter listed A as the dependency and libfoo is already installed via B, what is the mechanism in the ports infrastructure by which B gets registered as the dependency? B could have been installed 6 months ago before the user decided today that he wants to use C. Maybe there is no way right now to register the "installed" alternative dependency automatically. > However, if a porter misses listing a necessary dependency, then > things can get a little confused, and running "pkgdb -F" might > help... It's not that he missed listing a dependency. The problem is that he can't list both A & B - they conflict. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: conflicting dependency
Chuck Swiger wrote at 10:44 -0400 on Jul 20, 2006: > > If the porter listed A as the dependency and libfoo is already > > installed via B, what is the mechanism in the ports infrastructure by > > which B gets registered as the dependency? > > The package database keeps track of all files installed by ports and knows > which port installed which file. See "man pkg_which". Then I am seeing different behavior for some reason. I see a @pkgdep entry for an uninstalled port. I'll see if I can track down why. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
Doug Barton wrote at 13:45 -0800 on Jan 12, 2008:
> I have actually advocated in the past that ALL ports should have version
> numbers, and that we then create virtual ports (symlinks, whatever) that
> point to whatever is the "current" version of that software. Different
> developers dislike that idea for different reasons, but my opinion is
> still that from the user perspective this would make life a lot easier.
I do this for a site-wide nfs shared installed apps dir at work
(ignoring the many edge cases, it's basically this: install to
PREFIX=/site/dist/${PKGNAME} and make sym links to /site/bin,
/site/lib). It's not particularly easy given the current ports
propensity to have everything in /usr/local, but I find it worthwhile.
It does make life easier (for both users and admins) for at least a
few reasons:
- multiple versions of the same port can co-exist (sometimes until a
newer one is proven to work)
- live upgrades don't affect people that may be running an older
version of a port since the old port is still around (and
just re-pointing a sym link to the new version doesn't make
an existing running instance of a program fail).
- updates are generally transparent to users
- having a common shared nfs dir means only having to install
a port once and all machines instantly get access.
I have my own hacks to the port tree to accomodate this strategy. And
no, I won't publish them as they are quite hacky in places, but if
there were moves in the direction you describe (not likely as far as I
can see due to resistance of the kind you described - and it's not a
particularly small task to support something like this officially), I
could chime in about how I've been doing it for the last 10 years.
Ports based on pkg-config have made this much easier, and for those
ports I almost don't have to do anything special at all except set
PREFIX to point somewhere other than /usr/local.
It's had some bumps in the road over the years, but it mostly just
works now.
I must say it's been much nicer now that the pointyhat checks for
ports that don't handle PREFIX properly. 10 years ago that was a much
more prevalent problem.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USE_LINUX_RPM and PORTDOCS
Alexander Leidinger wrote at 19:35 +0200 on May 24, 2008: > Removing unwanted stuff in post-extract is not uncommon. I don't think > a patch for linux-rpm.mk with something like this would be a bad > solution. Removing things in post-extract _should_ be uncommon. If I want to look at the extraction of the distfile(s), running 'make extract' should give me that without removing things. I think I've heard others echo that sentiment. Why not pre- or post-patch - part of a stage that implies a modification of unpacked distfile(s)? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USE_LDCONFIG & linux ports
Careful about using USE_LDCONFIG with linux ports. With the current ports infrastructure you may wind up running ldconfig on the native ldconfig database (i.e., without -r /compat/linux). As an example, try replacing INSTALLS_SHLIB=yes with USE_LDCONFIG=yes in x11/linux-xorg-libs/Makefile. Then run make install. It will do this: . . ===> Running ldconfig /sbin/ldconfig -m /compat/linux/lib . . (note the lack of '-r /compat/linux') If you try it, I recommend you do this in a chroot, just in case ;). The root of the cause is that the old way (INSTALLS_SHLIB) uses LDCONFIG_CMD. The new way (USE_LDCONFIG) uses LDCONFIG. Having USE_LINUX_PREFIX causes bsd.port.mk to add -r /compat/linux to LDCONFIG_CMD (and not LDCONFIG). I don't have a patch at the moment, but I would probably start by trying to use LDCONFIG instead of LDCONFIG_CMD in the USE_LINUX stuff in bsd.port.mk. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: GNOME 2.20.1 available for FreeBSD
Aryeh M. Friedman wrote at 23:53 -0400 on Oct 24, 2007: > ===> Configuring for lsof-4.79C > Unknown FreeBSD release: 8.0-CURRENT > Assuming FreeBSD 2.x > ./Configure: /usr/sbin/sysctl: not found Until sysutils/lsof is updated for 8.x, try this when running your portupgrade: env LSOF_VSTR=7.0-CURRENT portupgrade ... p.s. see the Configure script after 'make extract' in sysutils/lsof ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for DESTDIR: security/openssh-portable
Gábor Kövesdán wrote at 01:29 +0200 on Aug 10, 2006:
> John E Hein wrote:
> > John E Hein wrote at 16:31 -0600 on Aug 9, 2006:
> > > Now that ports/Mk does the right thing for DESTDIR (thanks to Gábor),
> > > here's a patch that supports DESTDIR properly for
> > > security/openssh-portable:
> > >
> > [snip]
> > > @@ -171,29 +171,33 @@ post-extract:
> > > post-patch:
> > > @${REINPLACE_CMD} -e 's|-ldes|-lcrypto|g' ${WRKSRC}/configure
> > >
> > > +.if defined(DESTDIR) && !empty(DESTDIR)
> > > +CHROOTDESTDIR=${CHROOT} ${DESTDIR}
> > > +.endif
> > > +
> > [snip]
> > > .endif
> > > - if ! pw groupshow sshd; then pw groupadd sshd -g 22; fi
> > > - if ! pw usershow sshd; then pw useradd sshd -g sshd -u 22 \
> > > + if ! ${CHROOTDESTDIR} pw groupshow sshd; then ${CHROOTDESTDIR}
> > pw groupadd sshd -g 22; fi
> > > + if ! ${CHROOTDESTDIR} pw usershow sshd; then ${CHROOTDESTDIR}
> > pw useradd sshd -g sshd -u 22 \
> > > -h - -d ${EMPTYDIR} -s /nonexistent -c "sshd privilege
> > separation"; fi
> >
> > Gabor, you may want to define CHROOTDESTDIR (or name it whatever you
> > want) as a convenience var in bsd.port.mk
> >
> > I suspect lots of ports will want to use it.
> >
> Might be good, but personally I think ${CHROOT} ${DESTDIR} is more
> trivial (easier to read and understand) and only longer with 4
> characters. One might wonder at first look what CHROOTDESTDIR is.
Well, the part that makes it annoying to duplicate in all ports is not
the two separate words (CHROOT DESTDIR), but that you have to test
defined(DESTDIR) && !empty(DESTDIR) before you can figure out whether
to use ${CHROOT} ${DESTDIR} or not.
So having that test to assign CHROOTDESTDIR or leave it empty in
bsd.port.mk allows the port writer to just always invoke it without
having to worry about testing for DESTDIR.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for DESTDIR: security/openssh-portable
John E Hein wrote at 17:43 -0600 on Aug 9, 2006:
> Well, the part that makes it annoying to duplicate in all ports is not
> the two separate words (CHROOT DESTDIR), but that you have to test
> defined(DESTDIR) && !empty(DESTDIR) before you can figure out whether
> to use ${CHROOT} ${DESTDIR} or not.
>
> So having that test to assign CHROOTDESTDIR or leave it empty in
> bsd.port.mk allows the port writer to just always invoke it without
> having to worry about testing for DESTDIR.
You could pass this var to pkg-install scripts, too (put it in the
standard *SUB* lists).
That way you don't have to do the dance that was added to
security/clamav/files/pkg-install.in:
if [ -n "%%DESTDIR%%" ]; then
PW="/usr/sbin/chroot %%DESTDIR%% pw"
CHOWN="/usr/sbin/chroot %%DESTDIR%% chown"
MKDIR="/usr/sbin/chroot %%DESTDIR%% mkdir -p"
else
PW="pw"
CHOWN="chown"
MKDIR="mkdir -p"
fi
but rather just:
PW="%%CHROOTDESTDIR%% pw"
CHOWN="%%CHROOTDESTDIR%% chown"
MKDIR="%%CHROOTDESTDIR%% mkdir -p"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for DESTDIR: security/openssh-portable
Gábor Kövesdán wrote at 01:47 +0200 on Aug 10, 2006: > Ah, you mean defining CHROOTDESTDIR only when DESTDIR is set and leave > it empty when not? It sounds reasonable then. I'll work this out after > some hours of sleeping. :) Yep... that's it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for DESTDIR: security/openssh-portable
John E Hein wrote at 11:55 -0600 on Aug 10, 2006:
> Brooks Davis wrote at 09:05 -0500 on Aug 10, 2006:
> > I think we should ideally introduce a feature to allow ports to
> > automatically run pkg-install and stuff the code in bsd.port.mk so
> > ports don't have to know about DESTDIR in this case.
>
> Yes. That'd be nice.
Clarifying 'nice'...
As you know, many custom install targets do:
${INSTALL_PROGRAM} foo ${PREFIX}/bin
Those should change to
${INSTALL_PROGRAM} foo ${DESTDIR}${PREFIX}/bin
or the shorthand:
${INSTALL_PROGRAM} foo ${TARGETDIR}/bin
So those ports need to know about DESTDIR anyway.
But I can't think of any reason offhand not to have the pkg-install
scripts run in the DESTDIR chroot so they wouldn't have to know about
DESTDIR.
And standardizing (in bsd.port.mk) how pkg-install is run from custom
*install targets would make the task of getting ports properly DESTDIR
compliant much easier.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for DESTDIR: security/openssh-portable
Brooks Davis wrote at 09:05 -0500 on Aug 10, 2006:
> My inclination would be something like:
>
> PKG_INSTALL_TEMP=`mktemp ${DESTDIR}/tmp/pkg_install` && \
> (${CAT} ${PKG_INSTALL} > ${PKG_INSTALL_TEMP}; \
> ${SH} ${PKG_INSTALL_TEMP}; \
> ${RM} ${PKG_INSTALL_TEMP})
I would just put PKG_INSTALL_TEMP in WRKDIR and not worry about mktemp
& rm. I do something similar in my local tree for a pkg-install that
is slightly different when run from the 'install' target than the
one installed in PKG_DBDIR.
> I think we should ideally introduce a feature to allow ports to
> automatically run pkg-install and stuff the code in bsd.port.mk so
> ports don't have to know about DESTDIR in this case.
Yes. That'd be nice.
> Actually, ports where pkg-install and the pre/post-install targets
> duplicate code (often slightly differently) drive me nuts so I'd
> prefer a NO_AUTOPKGINSTALL, but that would take some real work so a
> positive flag is probably better initially.
Agreed. That duplication is definitely a candidate for cleanup.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Gábor Kövesdán wrote at 11:32 +0200 on Aug 15, 2006:
> Dmitry Marakasov wrote:
> > Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
> > absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
> > DESTDIR. But, these variables are frequently used when changing paths
> > hardcoded in port's sources (see many of my ports, for example
> > games/fishsupper:
> >
> > @${REINPLACE_CMD} -e 's|data/|${DATADIR}/|'
> > ${WRKSRC}/src/getreadydisplay.cc
> >
> > After change, all these ports will not support DESTDIR automatically.
> > Incomplete list of such ports:
> >
> > find /usr/ports -name Makefile -exec grep -E \
> >"REINPLACE_CMD.*(DATADIR|LOCALBASE|X11BASE)" {}
> >
> > Now, if we want to fix these, we'll need to change variables in
> > REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_REL
> > and DATADIR... hmm, we have no DATADIR_REL, so all is left is
> > ${PREFIX}/share/${PORTNAME}. That's unforgivable.
>
> Yes, that's right as well, but note if we had left LOCALBASE, LINUXBASE,
> X11BASE unchanged, we would need to change them in the *_DEPENDS lines.
> That's true that we don't have DATADIR_REL, etc. We could introduce them
> if needed, but that substitution can be done with make :S as well.
> DESTDIR implementation is complicated in many ways, no perfect
> implementation exist. As you said LOCALBASE is used in substitutions, bu
> also used in *_DEPENDS as well. Now those two cases have to be
> distinguished. One of them should have been changed at all... That's why
> I say no perfect implementation exist. If we implement new functions
> later, it can be very difficult...
I haven't followed any of this thread, so I apologize for rehashing
anything that's already been beaten to death.
First comment: MOST of the time people should be installing to
${DESTDIR}${PREFIX} (aka ${TARGETDIR}) anyway rather than
${DESTDIR}${LOCALBASE}. If anyone is using LOCALBASE for installs
rather than PREFIX, in most cases, that is wrong. If you install
directly to LOCALBASE, you are no longer PREFIX clean.
Second comment: the way DESTDIR was hacked into bsd.port.mk from the
beginning was wrong (/usr/share/mk/*.mk treats it correctly). We
could either accept that as it has been for a long time or try to fix
it.
Once you accept that the longstanding usage of DESTDIR in ports is
bogus, then you need to think about how to fix it.
Unfortunately, individual ports (port writers) need to be aware,
to some degree, about the proper meaning of DESTDIR. Until all third
party software uses the same method to build and install their
software (never), not everything can be fixed in bsd.port.mk.
Now, let's take LOCALBASE. You could have a version of LOCALBASE (1)
that has DESTDIR in it. You could have another version without
DESTDIR (2). You need to use the right one at the right time (general
rule: anything to do with installing needs DESTDIR; anything at build
time or run time doesn't; the complicated part comes in when you are
trying to build a package - some places need DESTDIR, some don't - the
pkg* tools could be fixed to understand DESTDIR better, but that's
another story altogether).
In my original patch (ports/28155), I chose to have (1) called
${DESTDIR}${LOCALBASE} and (2) called LOCALBASE. This would allow a
certain class of uses of LOCALBASE to remain unchanged... but not all.
Gábor chose to have (1) called LOCALBASE and (2) called LOCALBASE_REL.
Fine. This allows a different class of uses of LOCALBASE to remain
unchanged... but, again, not all.
You could call (1) FOO and (2) BAR. That would require LOTS of
changes, of course.
You could also call (1) ${LOCALBASE:C/^/${DESTDIR}/} and (2) LOCALBASE.
And so on and so on.
Which method requires the fewest changes to individual ports is an
exercise for the reader. But the difference is probably not
consequential enough to worry about.
The hard part is to get ports writers to think the right way about
DESTDIR after ignoring it for so many years. And once you decide to
go about fixing it, there's no way around that problem.
> > What I propose is:
> > - Change variable naming scheme.
> > All *BASE and *DIR vars should be reverted to their original meanings
> > (i.e. local paths). Instead, INSTALL_ vars should be introduced:
> > INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE}
> > INSTALL_X11BASE=${DESTDIR}/${X11BASE}
> > INSTALL_PREFIX=${DESTDIR}/${PREFIX}
> > INSTALL_DATADIR=${DESTDIR}/${DATADIR}
I understand where you're coming from, Dmitry. It's one way to do it.
It's more like my original way. I chose to not name that variable at
all, however - individual ports would just call it
${DESTDIR}${LOCALBASE} (or more correctly ${DESTDIR}${PREFIX} in most
situations).
You may think it's the better way. It may be that someone performs
the exercise I mentioned above to count the number of changes one way
requires vs. the other way and finds it to be the case.
That
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Kris Kennaway wrote at 13:36 -0400 on Aug 16, 2006:
> mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
> mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
> mount_devfs foo ${DESTDIR}/dev
> chroot ${DESTDIR} cd ${.CURDIR} && make install
>
> A suitable version of the above should allow all ports to be installed
> into a jail-ready filesystem hierarchy, while requiring 0 port
> changes.
I do that, too - we _have_ to since DESTDIR never worked right.
That's more heavyweight than a DESTDIR chroot (which doesn't need to
have much more than pkg* tools & libc & a few others), but that's a
very minor advantage over a full chroot (and probably not worth trying
to special case). My original DESTDIR "fix" didn't involve a chroot
at all, but runs into problems with pkg management.
Note that if we go that route (just run completely within a chroot),
we might as well just rip DESTDIR support out of Mk/*.mk altogether.
That would be better than the "fake" support for DESTDIR.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Gábor Kövesdán wrote at 21:44 +0200 on Aug 23, 2006:
> Kris Kennaway wrote:
> > mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
> > mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
> > mount_devfs foo ${DESTDIR}/dev
> > chroot ${DESTDIR} cd ${.CURDIR} && make install
> >
> > A suitable version of the above should allow all ports to be installed
> > into a jail-ready filesystem hierarchy, while requiring 0 port
> > changes.
>
> Ok, I think it's time to follow this way, but have to make some parts
> clearer. For your last line, it should be
>
> chroot ${DESTDIR} cd ${.CURDIR} && make ${.TARGETDIR}
I assume you mean .TARGET
> since we want to run all targets chrooted. We could put this part into
> an .if defined(DESTDIR) block before the targets, but I don't know how
> to prevent running the further code, since we don't want to reach
> do-install in the host environment, but only in the chroot. I think of
> exit 0, if that's correct, or what else is better.
> So, what I mean:
>
> .if defined(DESTDIR)
> .BEGIN # We need this if not in a target
> ${MOUNT_NULLFS} ${PORTSDIR} ${DESTDIR}${PORTSDIR}
> ${MOUNT_NULLFS} ${WRKDIR} ${DESTDIR}${WRKDIR}
> ${MOUNT_DEVFS} foo ${DESTDIR}/dev
> ${CHROOT} ${DESTDIR} cd ${.CURDIR} && ${MAKE} ${.TARGETDIR}
> exit 0
> .endif
Each line with a command in a makefile is it's own shell.
So 'exit 0' will start a shell and exit that shell.
It will not prevent make from continuing.
'exit 1' (or anything that returns a non-zero code, like false) will
stop make (unless -k or -i or similar is specified), but that's not
what you want.
make(1) is not a very good tool for this kind of thing (a script would
probably be better), but here is one way to do this kind of two stage
make (untested, but illustrates the point):
bsd.port.mk would have something like this:
STAGE?= 1
.if ${STAGE} == 1 && defined(DESTDIR) && !empty(DESTDIR)
.MAKEFLAGS: STAGE=2
.BEGIN:
${MOUNT_NULLFS} ${PORTSDIR} ${DESTDIR}${PORTSDIR}
${MOUNT_NULLFS} ${WRKDIR} ${DESTDIR}${WRKDIR}
${MOUNT_DEVFS} foo ${DESTDIR}/dev
${CHROOT} ${DESTDIR} cd ${.CURDIR} && ${MAKE} ${.TARGET}
.else
.
.
rest of bsd.port.mk
.
.
.endif
You could put the first part into a bsd.destdir.mk and .include it
to make it look cleaner.
Note there are other complications like unmounting the nullfs and
devfs.
> The another issue I find is how we can pass variables to the chrooted
> make. E.g. if we want to set WITH_FOO in command line or in make.conf.
> And note, that we can't just pass everything, since DESTDIR should be
> unset in the chroot, otherwise we would run into infinite loop and it
> would fail due to the non-existent directories.
Really, for these and other reasons, a script would be better. It
could be done with make(1) and bsd.port.mk, but it's probably not
worth it.
Again, if we do decide to go this route, we should remove all mention
of DESTDIR from Mk/*.mk (rather than pretend to support it, but
incorrectly).
Others have mentioned cross building. Neither proper DESTDIR support
in bsd.port.mk nor a scripted mount_nullfs & a chroot is going to be
the one thing to solve that problem. Some ports will build okay if
you give them access to cross tools (like ppc-gcc) and tell them what
target architecture to produce. Other ports will need to be taught.
Some ports might need to run intermediate native architecture tools
produced at build time in order to produce the final cross arch
product. It's not as simple as just being able to install to an
alternate location. And I don't think it matters much how ports/Mk
handles DESTDIR. There are bigger issues.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
update to opentaxsolver 4.01 (for 2006)
>Submitter-Id: current-users
>Originator: John E. Hein
>Organization:
>Confidential: no
>Synopsis: update to opentaxsolver 4.01 (for 2006)
>Severity: non-critical
>Priority: low
>Category: ports
>Class: maintainer-update
>Release: FreeBSD 4.x+
>Environment: FreeBSD 4.x+
>Description:
opentaxsolver 4.01 was recently released (US tax forms only
at the moment; state forms coming "soon").
This is the first update for tax year 2006. As such, this
conflicts with the last version for 2005 (3.08).
Perhaps there should be a different version of the port for each
tax year (at least for a few years back). I'm not sure it's
worth it... people can always mine CVS to get an older version
when they get audited a couple years later ;)
If there is enough demand for that, perhaps a repo copy (and
then possibly rename some installed files as appropriate) of
the existing port from opentaxsolver to opentaxsolver2005
is the way to go. If that is desired I'll look into a repo
copy and any subsequent mods required to rename anything
that conflicts with the current version.
Most of the files, except the gui, have the tax year in the name.
So I may be able to just add to the port so versions from years past can
co-exist. I'll look into that, but I am comfortable with
committing this patch to update to tax year 2006 and add back
support for years gone by later.
>How-To-Repeat:
Apply patch below.
Do a test build.
Commit.
>Fix:
Index: Makefile
===
RCS file: /base/FreeBSD-CVS/ports/finance/opentaxsolver/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile24 Nov 2006 21:21:25 - 1.2
+++ Makefile7 Jan 2007 19:14:39 -
@@ -6,12 +6,11 @@
#
PORTNAME= ${UPPORTNAME:L}
-PORTVERSION= 3.08
+PORTVERSION= 4.01
CATEGORIES=finance
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=opentaxsolver
-DISTNAME= ${UPPORTNAME}2005_${PORTVERSION}
-EXTRACT_SUFX= .tgz
+DISTNAME= ${UPPORTNAME}2006_${PORTVERSION}
MAINTAINER=[EMAIL PROTECTED]
COMMENT= US tax prep software
Index: distinfo
===
RCS file: /base/FreeBSD-CVS/ports/finance/opentaxsolver/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo24 Nov 2006 21:21:25 - 1.2
+++ distinfo7 Jan 2007 17:53:49 -
@@ -1,3 +1,2 @@
-MD5 (OpenTaxSolver2005_3.08.tgz) = 7467cc72d85b2a88366046cf7c52719c
-SHA256 (OpenTaxSolver2005_3.08.tgz) =
01d691b367b82f818c0baa227a65189a04a68a02c7b8f6163b955e65901b1a03
-SIZE (OpenTaxSolver2005_3.08.tgz) = 224468
+MD5 (OpenTaxSolver2006_4.01.tar.gz) = 9ce67ed03a38c54cf1258051835615e0
+SIZE (OpenTaxSolver2006_4.01.tar.gz) = 180586
Index: pkg-plist
===
RCS file: /base/FreeBSD-CVS/ports/finance/opentaxsolver/pkg-plist,v
retrieving revision 1.2
diff -u -p -r1.2 pkg-plist
--- pkg-plist 24 Nov 2006 21:21:25 - 1.2
+++ pkg-plist 7 Jan 2007 17:53:49 -
@@ -1,53 +1,14 @@
bin/ots_gui
-bin/taxsolve_CA_540_2005
-bin/taxsolve_MA_1_2005
-bin/taxsolve_NJ_1040_2005
-bin/taxsolve_NY_IT201_2005
-bin/taxsolve_OH_IT1040_2005
-bin/taxsolve_PA_40_2005
-bin/taxsolve_US_1040_2005
-bin/taxsolve_US_1040_Sched_C_2005
-bin/taxsolve_VA_760_2005
+bin/taxsolve_US_1040_2006
+bin/taxsolve_US_1040_Sched_C_2006
share/ots/otslogo.ppm
-share/ots/examples_and_templates/CA_540/CA_540_2005_example.dat
-share/ots/examples_and_templates/CA_540/CA_540_2005_template.dat
-share/ots/examples_and_templates/CA_540/README_CA_540.txt
-share/ots/examples_and_templates/MA_1/MA_1_2005_example.dat
-share/ots/examples_and_templates/MA_1/MA_1_2005_template.dat
-share/ots/examples_and_templates/MA_1/README_MA_1.txt
-share/ots/examples_and_templates/NC_400/NC_400_2005_example.dat
-share/ots/examples_and_templates/NC_400/NC_400_2005_template.dat
-share/ots/examples_and_templates/NC_400/README_NC_400.txt
-share/ots/examples_and_templates/NJ_1040/NJ_1040_2005_example.dat
-share/ots/examples_and_templates/NJ_1040/NJ_1040_2005_template.dat
-share/ots/examples_and_templates/NJ_1040/README_NJ_1040.txt
-share/ots/examples_and_templates/NY_IT201/NY_IT201_2004_example.dat
-share/ots/examples_and_templates/NY_IT201/NY_IT201_2004_template.dat
-share/ots/examples_and_templates/NY_IT201/README_NY_IT201.txt
-share/ots/examples_and_templates/OH_1040/OH_IT1040_2005_example.dat
-share/ots/examples_and_templates/OH_1040/OH_IT1040_2005_template.dat
-share/ots/examples_and_templates/OH_1040/README_OH_IT1040.txt
-share/ots/examples_and_templates/PA_40/PA_40_2005_example.dat
-share/ots/examples_and_templates/PA_40/PA_40_20
