Re: ports/*/jpeg "Thanks a lot guys"
On Sun, Aug 2, 2009 at 7:52 AM, Matthew Seaman wrote: Matthew Seaman wrote: Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about time I released an update anyhow -- I'll code up a little app that processes the LIB_DEPENDS linkages already stored in the cache and lists each port that has a LIB_DEPENDS, together with all the ports it depends on cumulatively. I've got this working now -- I still need to do some more testing, update documentation and stuff before I release version 2.2 of p5-FreeBSD-Portindex, Version 2.2 now released: http://www.infracaninophile.co.uk/portindex/ Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Ideas upon the port infrastructure. [MOVED] was "ports/*/jpeg "Thanks a lot guys""
That is a very nice idea, I am sure that with a little tweaking it would turn
out just fine.
Another nice aspect or solve for this would be getting something going like
symbol versioning in the libs by means of the developer that supports 2 or so
version's prior to the current lib in order to ease upgrading on any system
rather than just FreeBSD. I am certainly no expert in that field so I can not
comment more.
More comments ? any other takers. "Brain storming session"
On Fri, 7 Aug 2009 07:13:31 +0800
Buganini wrote:
> The meaning of NODE_VERSION and the flag is to describe dependencies more
> detailed,
> to make it possible to do automated upgrade, instead of bump PORTREVISION by
> man.
>
> An important thing, NODE_VERSION and the flag could be backward compatible,
> for port/package don't have NODE_VERSION, it's just 0.
> the flag could be just a '!' prefix, for example:
> !fltk-threads>=1.1.9:${PORTSDIR}/x11-toolkits/fltk-threads
> QT_COMPONENTS= gui imageformats_run moc_build !qmake_build !uic_build
> without the flag, everything is just like how it is now.
>
> this should be enough for cases like this jpeg case.
> For more detail, if we only save NODE_VERSION of port itself in +CONTENTS
> upgrade MUST be transactional, but for portupgrade and portmaster, exit in
> half way is usual,
> so I think to save NODE_VERSION of each dependencies is also necessary,
> or even make it part of version string, but this may be confused for
> somebody I think.
>
> For the upgrade of perl, now we use port* -o to replace, then -r or -fr to
> rebulid required-by
> If we have
> NODE_VERSION=5.8.0 in lang/perl5.8
> NODE_VERSION=5.10.0 in lang/perl5.10
> then when we port{upgrade,master} -o lang/perl5.10 perl5.8
> we dont have to rebuild required-by manually anymore.
>
> Furthermore, a unified target post-upgrade: is good, some ports has already
> have this,
> for example, upgrade-site-packages in lang/python
>
> --Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
The meaning of NODE_VERSION and the flag is to describe dependencies more
detailed,
to make it possible to do automated upgrade, instead of bump PORTREVISION by
man.
An important thing, NODE_VERSION and the flag could be backward compatible,
for port/package don't have NODE_VERSION, it's just 0.
the flag could be just a '!' prefix, for example:
!fltk-threads>=1.1.9:${PORTSDIR}/x11-toolkits/fltk-threads
QT_COMPONENTS= gui imageformats_run moc_build !qmake_build !uic_build
without the flag, everything is just like how it is now.
this should be enough for cases like this jpeg case.
For more detail, if we only save NODE_VERSION of port itself in +CONTENTS
upgrade MUST be transactional, but for portupgrade and portmaster, exit in
half way is usual,
so I think to save NODE_VERSION of each dependencies is also necessary,
or even make it part of version string, but this may be confused for
somebody I think.
For the upgrade of perl, now we use port* -o to replace, then -r or -fr to
rebulid required-by
If we have
NODE_VERSION=5.8.0 in lang/perl5.8
NODE_VERSION=5.10.0 in lang/perl5.10
then when we port{upgrade,master} -o lang/perl5.10 perl5.8
we dont have to rebuild required-by manually anymore.
Furthermore, a unified target post-upgrade: is good, some ports has already
have this,
for example, upgrade-site-packages in lang/python
--Buganini
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
I believe unless I misunderstand what you are meaning, is the same thing that
PORTREVISION is meant for doing. If the maintainer like what has just recently
happened for jpeg bumps the PORTREVISION up one for every port that depends on
jpeg then any upgrade utilities see that port as a new version and upgrade them
happily.
PORTREVISION is the end of the package name as package-VERSION-{ , or _
}PORTREVISION.
Personally I feel that adding another NODE_VERSION as your saying could
possibly be a benefit but at this time would cause a lot of maintainer overhead
on which that they already have. I think more of a short written policy or
checklist system for a maintainer might be a better route. Or possibly a ticket
system built around a dependency checklist that should be fulfilled before a
commit on a newer version would happen. Even with the previous statement that
still causes overhead in workload but eventually speeds the process up due to
lack of errors and re-corrections that have to be made ultimately resulting in
a higher percent of satisfied hobbyists and customers alike thus bringing in
more revenue.
If I could be of more assistance on this matter I have great experience
satisfying time tested analytics that speed up processes in the form of Lean
Manufacturing also plays a role in development.
Best regards.
On Thu, 6 Aug 2009 12:46:12 +0800
Buganini wrote:
> Recently I'm think about how to make ports easier to upgraded:
> 1) Add a NODE_VERSION in each ports' Makefile, this variable would be stored
> in +CONTENTS.
> 2) Add a volatile-meaning flag in description of dependencies
>
> When a port, A, whose NODE_VERSION in Makefile > NODE_VERSION in +CONTENTS,
> ports that volatile'ly depends on A would be rebuilt.
>
> Any comment is welcome
>
> --Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Recently I'm think about how to make ports easier to upgraded: 1) Add a NODE_VERSION in each ports' Makefile, this variable would be stored in +CONTENTS. 2) Add a volatile-meaning flag in description of dependencies When a port, A, whose NODE_VERSION in Makefile > NODE_VERSION in +CONTENTS, ports that volatile'ly depends on A would be rebuilt. Any comment is welcome --Buganini ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Sunday 02 August 2009 06:52:03 Matthew Seaman wrote:
> Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS
> on libmysqlclient.so.X added to their dependency mix even if they contain
> no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin]
That's because you use USE_MYSQL when you really want to include
bsd.databases.mk and throw and error on specific mysql versions.
This could be addressed as below and for similar Mk/* files, should
it be needed:
Index: Mk/bsd.database.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.database.mk,v
retrieving revision 1.37
diff -u -r1.37 bsd.database.mk
--- Mk/bsd.database.mk 21 Jul 2009 08:02:18 - 1.37
+++ Mk/bsd.database.mk 4 Aug 2009 06:59:12 -
@@ -158,7 +158,7 @@
.if (${USE_MYSQL} == "embedded")
BUILD_DEPENDS+=
${LOCALBASE}/lib/mysql/libmysqld.a:${PORTSDIR}/databases/mysql${MYSQL_VER}-server
.endif
-.else
+.elif (${USE_MYSQL} != "vcheck")
LIB_DEPENDS+=
mysqlclient.${MYSQL${MYSQL_VER}_LIBVER}:${PORTSDIR}/databases/mysql${MYSQL_VER}-client
.endif
.else
Index: databases/phpmyadmin/Makefile
===
RCS file: /home/ncvs/ports/databases/phpmyadmin/Makefile,v
retrieving revision 1.108
diff -u -r1.108 Makefile
--- databases/phpmyadmin/Makefile 30 Jun 2009 19:10:53 - 1.108
+++ databases/phpmyadmin/Makefile 4 Aug 2009 07:00:04 -
@@ -14,7 +14,7 @@
MAINTAINER=m.sea...@infracaninophile.co.uk
COMMENT= A set of PHP-scripts to manage MySQL over the web
-USE_MYSQL= yes
+USE_MYSQL= vcheck
IGNORE_WITH_PHP= 4
IGNORE_WITH_MYSQL= 323 40 41
USE_BZIP2= yes
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Doug Barton wrote: Garrett Cooper wrote: Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) has a script called `revdep-rebuild' which goes and runs ldd on all pieces of software that are installed in portage (ok, substitute ports here). What I'm driving at is that we can use pkg_info and/or the mtree generated files to determine what files are installed, find out which packages have been broken up an update, then rebuild the port and all dependencies (LIB_DEPENDS?). What say you to that :)? I was experimenting with various scripts using ldd in parallel to my most recent portmaster update and I think there is a problem with that solution. If libA is linked against libB which in turn is linked against libMISSING (such as libjpeg.so.9 for example) then ldd against libA will show libMISSING even though that problem can be solved by simply updating libB (i.e., without recompiling libA). This same issue applies to the idea of running ldd against things at install time and recording the list. Is that sufficient? If the ABI changes to libMISSING change its size such that it uses a different number of 4k memory pages, doesn't that change the load address of any subsequently loaded shlibs? Showing direct vs indirect linkage seems to be what 'ldd -a' does, although I think given the above you'ld have to rebuild anything that linked, directly or indirectly, against libMISSING. Perhaps someone smarter than I about ldd can come up with a solution to this, but until then I think that using ldd after the fact is a stopgap measure to repair things if the ports infrastructure fails us. A script for scanning the ldd(1) output would be useful for port maintainers primarily IMHO. In theory the dependency graphing in our existing ports infrastructure should deal with this problem. In practice at the moment I personally feel that we record too many "indirect" dependencies (such as libA above) and that we would serve our users better if we stuck to direct dependencies only (libB in the example above). What should have happened in this case is that the ports that depend DIRECTLY on libjpeg should have had their revisions bumped at the same time as the update to libjpeg. Since that is what usually happens, hopefully we can stop flogging this horse soon. What usually seems to happen is that any port with a RUN_DEPENDS on the port providing the shlib in question gets a portrevision bump, including many where it makes no sense to do so. Tracking LIB_DEPENDS would be my choice for dealing with this problem, but as you say, there would need to be a ports-wide review and rationalisation of LIB_DEPENDS settings. That said, if anyone really really wants to pursue the dependency graphing issue further, can I suggest a new thread focused on that topic? What's wrong with the thread we've already got? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports/*/jpeg "Thanks a lot guys"
On Saturday 01 August 2009 14:43:23 Peter Jeremy wrote:
> [I was also dismayed when I saw the bump].
>
> On 2009-Aug-01 18:33:43 +0100, Matthew Seaman
> wrote:
> >You could, for instance, run ldd(1) against each of the files a port
> > installs and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or
> > equivalently in the .tbz package tarball a sorted and uniq'd list of all
> > the shared libraries linked against.
>
> Unfortunately, this isn't sufficient because a non-trivial number of
> ports dlopen() libraries rather than directly linking against them.
> (The Xorg server is probably the most widely used culprit here).
>
> > Or you could resolve the shlib filenames back to the ports
> >that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port
> >Makefiles.
>
> A third approach is to more carefully recurse through the dependency
> tree: Given A depends on B depends on C, B only needs bumping if it
> LIB_DEPENDS on A and C only needs bumping if it LIB_DEPENDS on B and
> B was bumped.
Unfortunately, qt4-* ports slice this idea. Because they don't use
LIB_DEPENDS, but a version dependant RUN and BUILD depends. I've coded a
"patch-recursive" target in my Mk/bsd.local.mk that can't depend just on
LIB_DEPENDS for this very reason (I needed the target so I can debug
crashes in kde4 programs, and have gdb's `list' command working).
--
Mel
_LIB_DEPEND_DIRS=${LIB_DEPENDS:C,^[^:]*:([^:]*).*$,\1,}
_QT4_DEPEND_DIRS=${BUILD_DEPENDS:Mqt4-*:C,^[^:]*:([^:]*).*$,\1,}
LIB-DEPENDS-LIST= \
L="${_LIB_DEPEND_DIRS} ${_QT4_DEPEND_DIRS}";\
checked=""; \
while [ -n "$$L" ]; do \
l=""; \
for d in $$L; do\
case $$checked in \
$$d\ *|*\ $$d\ *|*\ $$d)\
continue;; \
esac; \
checked="$$checked $$d";\
if [ ! -d $$d ]; then \
${ECHO_MSG} "${PKGNAME}: \"$$d\" non-existent -- dependency
list incomplete" >&2; \
continue; \
fi; \
${ECHO_CMD} $$d;\
if ! children=$$(cd $$d && ${MAKE} -V _LIB_DEPEND_DIRS); then\
${ECHO_MSG} "${PKGNAME}: \"$$d\" erroneous -- dependency list
incomplete" >&2; \
continue; \
fi; \
for child in $$children; do \
case "$$checked $$l" in \
$$child\ *|*\ $$child\ *|*\ $$child)\
continue;; \
esac; \
l="$$l $$child";\
done; \
done; \
L=$$l; \
done
patch-recursive:
@for dir in ${.CURDIR} $$(${LIB-DEPENDS-LIST}); do \
echo "===> $${dir}"; \
${MAKE} -C $${dir} patch; \
done
show-libdepends-recursive:
@for dir in ${.CURDIR} $$(${LIB-DEPENDS-LIST}); do \
echo "===> $${dir}"; \
done
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Garrett Cooper wrote: > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? I was experimenting with various scripts using ldd in parallel to my most recent portmaster update and I think there is a problem with that solution. If libA is linked against libB which in turn is linked against libMISSING (such as libjpeg.so.9 for example) then ldd against libA will show libMISSING even though that problem can be solved by simply updating libB (i.e., without recompiling libA). This same issue applies to the idea of running ldd against things at install time and recording the list. Perhaps someone smarter than I about ldd can come up with a solution to this, but until then I think that using ldd after the fact is a stopgap measure to repair things if the ports infrastructure fails us. In theory the dependency graphing in our existing ports infrastructure should deal with this problem. In practice at the moment I personally feel that we record too many "indirect" dependencies (such as libA above) and that we would serve our users better if we stuck to direct dependencies only (libB in the example above). What should have happened in this case is that the ports that depend DIRECTLY on libjpeg should have had their revisions bumped at the same time as the update to libjpeg. Since that is what usually happens, hopefully we can stop flogging this horse soon. That said, if anyone really really wants to pursue the dependency graphing issue further, can I suggest a new thread focused on that topic? hth, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Monday 03 August 2009 14:31:23 Matthew Seaman wrote: > There was a question about apps that use dlopen() to load libraries, > rather than letting ld.so do the work for them. I don't think that > using ldd(1) will pick up any app that does that, but then again I > don't know if this is a widespread practice, and if it is, whether > there is any simple way to pick out packages that need reinstallation > because of it other than by using manually defined LIB_DEPENDS > settings in port Makefiles. The most common use case for dlopen are plugins and there it's the app that controls the API, not the lib, so an update of the plugin without recompiling the app shouldn't be a problem. Use of dlopen to load normal libraries is rare, but an example is Wine. IMHO it's a bug if such libs aren't listed in LIB_DEPENDS. They are direct dependencies. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Garrett Cooper wrote: > On Sun, Aug 2, 2009 at 7:52 AM, Matthew > Seaman wrote: >> Matthew Seaman wrote: >> >>> Peter Jeremy wrote: In this specific case, p5-RT-* depends on www/rt38 depends on graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped because rt38 is not bumped. This is slighly more complex than cd /usr/ports && \ for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done | \ grep jpeg because you need to actually follow the dependency tree, but is not impractical. The only issues I can see with this approach are: 1) Mapping the shared library reported by 'make lib-depends' back to the port than installs it. 2) You are relying on LIB_DEPENDS being correct: In my general example above, if A is missing a LIB_DEPENDS on C, this may not be detected in the build process because of the implicit dependency on C via B. No sample script because I'm not sure of the correct approach to 1) off the top of my head. >>> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about >>> time I released an update anyhow -- I'll code up a little app that >>> processes >>> the LIB_DEPENDS linkages already stored in the cache and lists each port >>> that has a LIB_DEPENDS, together with all the ports it depends on >>> cumulatively. >> I've got this working now -- I still need to do some more testing, update >> documentation and stuff before I release version 2.2 of >> p5-FreeBSD-Portindex, >> but as a taster, here's the result of generating this on my machine just >> now: >> >> http://www.infracaninophile.co.uk/SHLIBS.bz2 >> >> (Note that this includes the effect of a number of local settings in >> /etc/make.conf) >> >> It's similar to the ports INDEX file, when decompressed. There's one row of >> the file for each port, and each row contains 3 fields separated by '|' >> characters: >> >> package-name|port/origin|space separated list of lib_depends port origins >> >> So, to extract the list of ports depending on www/jpeg: >> >> happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head >> -10 >> accerciser-1.6.1_1|/usr/ports/accessibility/accerciser >> at-poke-0.2.3_4|/usr/ports/accessibility/at-poke >> at-spi-1.26.0_1|/usr/ports/accessibility/at-spi >> dasher-4.10.1_1,2|/usr/ports/accessibility/dasher >> gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag >> gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus >> gok-2.26.0_1,1|/usr/ports/accessibility/gok >> kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility >> kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 >> mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks >> >> Again, this has a number of deficiencies. For instance, programs that >> embed a perl interpreter will link against libperl.so => >> /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register >> a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, >> www/mod_perl2] >> >> Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on >> libmysqlclient.so.X added to their dependency mix even if they contain >> no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] >> >> However, I think that the deficiencies are not too intractable to fix, >> and this approach shows some promise. > > There actually may be a much easier solution to this problem. > > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? > > If no one cares about the language, I can whip up a really quick > python script which solves this problem and we can migrate to a more > longterm solution in bourne shell if desired. If it's going to scan *all* of the installed files known to the pkg database to identify packages that depend on a particular shared library then it's going to take a pretty long time to run on a typical desktop package load. It would make sense to scan the installed files at package installation time and cache the result for each installed package, which is pretty much where I was at with the Bourne shell script I posted up-thread. There was a question about apps that use dlopen() to load libraries, rather than letting ld.so do the work for them. I don't think that usin
Re: ports/*/jpeg "Thanks a lot guys"
> On Sun, Aug 2, 2009 at 7:52 AM, Matthew > Seaman wrote: > > Matthew Seaman wrote: > > > >> Peter Jeremy wrote: > >>> > >>> In this specific case, p5-RT-* depends on www/rt38 depends on > >>> graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. > >>> When jpeg is bumped, gd needs to be bumped because it > >>> LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it > >>> LIB_DEPENDS on gd. rt38 does not need to be bumped because it > >>> has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped > >>> because rt38 is not bumped. > >>> > >>> This is slighly more complex than > >>> cd /usr/ports && \ > >>> for i in */*; do [ -d "$i" ] && cd "$i" && make > >>> all-depends-list ; done > >>> | \ > >>> grep jpeg > >>> because you need to actually follow the dependency tree, but is > >>> not impractical. The only issues I can see with this approach > >>> are: > >>> 1) Mapping the shared library reported by 'make lib-depends' back > >>> to the port than installs it. > >>> 2) You are relying on LIB_DEPENDS being correct: In my general > >>> example above, if A is missing a LIB_DEPENDS on C, this may not > >>> be detected in the build process because of the implicit > >>> dependency on C via B. > >>> > >>> No sample script because I'm not sure of the correct approach to > >>> 1) off the top of my head. > > > >> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's > >> about time I released an update anyhow -- I'll code up a little > >> app that processes > >> the LIB_DEPENDS linkages already stored in the cache and lists > >> each port that has a LIB_DEPENDS, together with all the ports it > >> depends on cumulatively. > > > > I've got this working now -- I still need to do some more testing, > > update documentation and stuff before I release version 2.2 of > > p5-FreeBSD-Portindex, > > but as a taster, here's the result of generating this on my machine > > just now: > > > > http://www.infracaninophile.co.uk/SHLIBS.bz2 > > > > (Note that this includes the effect of a number of local settings in > > /etc/make.conf) > > > > It's similar to the ports INDEX file, when decompressed. There's > > one row of the file for each port, and each row contains 3 fields > > separated by '|' characters: > > > > package-name|port/origin|space separated list of lib_depends port > > origins > > > > So, to extract the list of ports depending on www/jpeg: > > > > happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f > > 1-2 | head -10 > > accerciser-1.6.1_1|/usr/ports/accessibility/accerciser > > at-poke-0.2.3_4|/usr/ports/accessibility/at-poke > > at-spi-1.26.0_1|/usr/ports/accessibility/at-spi > > dasher-4.10.1_1,2|/usr/ports/accessibility/dasher > > gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag > > gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus > > gok-2.26.0_1,1|/usr/ports/accessibility/gok > > kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility > > kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 > > mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks > > > > Again, this has a number of deficiencies. For instance, programs > > that embed a perl interpreter will link against libperl.so => > > /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them > > register a LIB_DEPENDS on lang/perl5.10. [See for example > > net-mgmt/net-snmpd, www/mod_perl2] > > > > Similarly, programs that declare 'USE_MYSQL=NN' will have a > > LIB_DEPENDS on libmysqlclient.so.X added to their dependency mix > > even if they contain no compiled ELF binaries [See net-mgmt/cacti > > databases/phpmyadmin] > > > > However, I think that the deficiencies are not too intractable to > > fix, and this approach shows some promise. > > There actually may be a much easier solution to this problem. > > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? sysutils/bsdadminscripts provides a script called pkg_libchk which does a similar thing. Emanuel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Sun, Aug 2, 2009 at 7:52 AM, Matthew Seaman wrote: > Matthew Seaman wrote: > >> Peter Jeremy wrote: >>> >>> In this specific case, p5-RT-* depends on www/rt38 depends on >>> graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When >>> jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. >>> p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does >>> not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* >>> does not need to be bumped because rt38 is not bumped. >>> >>> This is slighly more complex than >>> cd /usr/ports && \ >>> for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done >>> | \ >>> grep jpeg >>> because you need to actually follow the dependency tree, but is not >>> impractical. The only issues I can see with this approach are: >>> 1) Mapping the shared library reported by 'make lib-depends' back to the >>> port than installs it. >>> 2) You are relying on LIB_DEPENDS being correct: In my general example >>> above, if A is missing a LIB_DEPENDS on C, this may not be detected >>> in the build process because of the implicit dependency on C via B. >>> >>> No sample script because I'm not sure of the correct approach to 1) off >>> the top of my head. > >> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about >> time I released an update anyhow -- I'll code up a little app that >> processes >> the LIB_DEPENDS linkages already stored in the cache and lists each port >> that has a LIB_DEPENDS, together with all the ports it depends on >> cumulatively. > > I've got this working now -- I still need to do some more testing, update > documentation and stuff before I release version 2.2 of > p5-FreeBSD-Portindex, > but as a taster, here's the result of generating this on my machine just > now: > > http://www.infracaninophile.co.uk/SHLIBS.bz2 > > (Note that this includes the effect of a number of local settings in > /etc/make.conf) > > It's similar to the ports INDEX file, when decompressed. There's one row of > the file for each port, and each row contains 3 fields separated by '|' > characters: > > package-name|port/origin|space separated list of lib_depends port origins > > So, to extract the list of ports depending on www/jpeg: > > happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head > -10 > accerciser-1.6.1_1|/usr/ports/accessibility/accerciser > at-poke-0.2.3_4|/usr/ports/accessibility/at-poke > at-spi-1.26.0_1|/usr/ports/accessibility/at-spi > dasher-4.10.1_1,2|/usr/ports/accessibility/dasher > gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag > gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus > gok-2.26.0_1,1|/usr/ports/accessibility/gok > kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility > kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 > mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks > > Again, this has a number of deficiencies. For instance, programs that > embed a perl interpreter will link against libperl.so => > /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register > a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, > www/mod_perl2] > > Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on > libmysqlclient.so.X added to their dependency mix even if they contain > no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] > > However, I think that the deficiencies are not too intractable to fix, > and this approach shows some promise. There actually may be a much easier solution to this problem. Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) has a script called `revdep-rebuild' which goes and runs ldd on all pieces of software that are installed in portage (ok, substitute ports here). What I'm driving at is that we can use pkg_info and/or the mtree generated files to determine what files are installed, find out which packages have been broken up an update, then rebuild the port and all dependencies (LIB_DEPENDS?). What say you to that :)? If no one cares about the language, I can whip up a really quick python script which solves this problem and we can migrate to a more longterm solution in bourne shell if desired. Thanks, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Matthew Seaman wrote: Peter Jeremy wrote: In this specific case, p5-RT-* depends on www/rt38 depends on graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped because rt38 is not bumped. This is slighly more complex than cd /usr/ports && \ for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done | \ grep jpeg because you need to actually follow the dependency tree, but is not impractical. The only issues I can see with this approach are: 1) Mapping the shared library reported by 'make lib-depends' back to the port than installs it. 2) You are relying on LIB_DEPENDS being correct: In my general example above, if A is missing a LIB_DEPENDS on C, this may not be detected in the build process because of the implicit dependency on C via B. No sample script because I'm not sure of the correct approach to 1) off the top of my head. Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about time I released an update anyhow -- I'll code up a little app that processes the LIB_DEPENDS linkages already stored in the cache and lists each port that has a LIB_DEPENDS, together with all the ports it depends on cumulatively. I've got this working now -- I still need to do some more testing, update documentation and stuff before I release version 2.2 of p5-FreeBSD-Portindex, but as a taster, here's the result of generating this on my machine just now: http://www.infracaninophile.co.uk/SHLIBS.bz2 (Note that this includes the effect of a number of local settings in /etc/make.conf) It's similar to the ports INDEX file, when decompressed. There's one row of the file for each port, and each row contains 3 fields separated by '|' characters: package-name|port/origin|space separated list of lib_depends port origins So, to extract the list of ports depending on www/jpeg: happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head -10 accerciser-1.6.1_1|/usr/ports/accessibility/accerciser at-poke-0.2.3_4|/usr/ports/accessibility/at-poke at-spi-1.26.0_1|/usr/ports/accessibility/at-spi dasher-4.10.1_1,2|/usr/ports/accessibility/dasher gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus gok-2.26.0_1,1|/usr/ports/accessibility/gok kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks Again, this has a number of deficiencies. For instance, programs that embed a perl interpreter will link against libperl.so => /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, www/mod_perl2] Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on libmysqlclient.so.X added to their dependency mix even if they contain no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] However, I think that the deficiencies are not too intractable to fix, and this approach shows some promise. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports/*/jpeg "Thanks a lot guys"
Peter Jeremy wrote: [I was also dismayed when I saw the bump]. On 2009-Aug-01 18:33:43 +0100, Matthew Seaman wrote: You could, for instance, run ldd(1) against each of the files a port installs and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or equivalently in the .tbz package tarball a sorted and uniq'd list of all the shared libraries linked against. Unfortunately, this isn't sufficient because a non-trivial number of ports dlopen() libraries rather than directly linking against them. (The Xorg server is probably the most widely used culprit here). Yes. There's also a problem with ports like firefox and openoffice that dynamically link against shared libraries not on the usual LD_LIBRARY_PATH. Still, what I wrote is still useful as a tool for providing a starting point on recording shared library dependencies. Or you could resolve the shlib filenames back to the ports that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port Makefiles. A third approach is to more carefully recurse through the dependency tree: Given A depends on B depends on C, B only needs bumping if it LIB_DEPENDS on A and C only needs bumping if it LIB_DEPENDS on B and B was bumped. I considered this, but didn't think it would be as complete as using ldd(1). Maybe I was wrong there -- but I've still a nagging feeling that this will miss out some cases. Also, LIB_DEPENDS only covers the first generation dependencies -- if your shared library itself depends on another shared library, that data would have to be accounted for by recursing through the dependency tree. (Your case (2) below) This is all doable: INDEX generation does virtually the same thing with BUILD_DEPENDS and RUN_DEPENDS. In fact, adding another field to the INDEX showing shlib dependencies would be a handy way of making the data accessible. In this specific case, p5-RT-* depends on www/rt38 depends on graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped because rt38 is not bumped. This is slighly more complex than cd /usr/ports && \ for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done | \ grep jpeg because you need to actually follow the dependency tree, but is not impractical. The only issues I can see with this approach are: 1) Mapping the shared library reported by 'make lib-depends' back to the port than installs it. 2) You are relying on LIB_DEPENDS being correct: In my general example above, if A is missing a LIB_DEPENDS on C, this may not be detected in the build process because of the implicit dependency on C via B. No sample script because I'm not sure of the correct approach to 1) off the top of my head. Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about time I released an update anyhow -- I'll code up a little app that processes the LIB_DEPENDS linkages already stored in the cache and lists each port that has a LIB_DEPENDS, together with all the ports it depends on cumulatively. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports/*/jpeg "Thanks a lot guys"
[I was also dismayed when I saw the bump]. On 2009-Aug-01 18:33:43 +0100, Matthew Seaman wrote: >You could, for instance, run ldd(1) against each of the files a port installs >and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or equivalently in the >.tbz package tarball a sorted and uniq'd list of all the shared libraries >linked against. Unfortunately, this isn't sufficient because a non-trivial number of ports dlopen() libraries rather than directly linking against them. (The Xorg server is probably the most widely used culprit here). > Or you could resolve the shlib filenames back to the ports >that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port >Makefiles. A third approach is to more carefully recurse through the dependency tree: Given A depends on B depends on C, B only needs bumping if it LIB_DEPENDS on A and C only needs bumping if it LIB_DEPENDS on B and B was bumped. In this specific case, p5-RT-* depends on www/rt38 depends on graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped because rt38 is not bumped. This is slighly more complex than cd /usr/ports && \ for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done | \ grep jpeg because you need to actually follow the dependency tree, but is not impractical. The only issues I can see with this approach are: 1) Mapping the shared library reported by 'make lib-depends' back to the port than installs it. 2) You are relying on LIB_DEPENDS being correct: In my general example above, if A is missing a LIB_DEPENDS on C, this may not be detected in the build process because of the implicit dependency on C via B. No sample script because I'm not sure of the correct approach to 1) off the top of my head. -- Peter Jeremy pgpPkGGNXQY2A.pgp Description: PGP signature
Re: ports/*/jpeg "Thanks a lot guys"
Dirk Meyer wrote:
Hallo Matthew Seaman,
The OP does have a valid point though. I just got an e-mail from Freshpo=
rts
saying that a bunch of ports I maintain had had PORTREVISION bumps becaus=
e of
the jpeg update. Which is all fine and dandy, except that these were the=
=20
www/p5-RT-* extension modules for RT. First of all, they are pure perl: =
there's
no object linkage with the jpeg shlibs at all. Secondly, they have nothi=
ng
to do with manipulating jpeg data in any way, shape or form. One of thei=
r
dependencies links against libjpeg: that's it.
This may be, but the port has "libjpeg" as dependency listed.
ports/www/p5-RT-Authen-ExternalAuth$ make all-depends-list | grep jpeg
/usr/ports/graphics/jpeg
ports/www/p5-RT-Extension-SLA$ make all-depends-list | grep jpeg
/usr/ports/graphics/jpeg
Yeah. That's because p5-RT-* {run-,build-} depend on www/rt38, and www/rt38
depends on graphics/p5-GD, which depends on graphics/gd, which depends on
graphics/jpeg.
Of that whole dependency chain only graphics/gd and graphics/p5-GD need
a PORTREVISION bump due to the libjpeg update.
Sorry I had no way to detect if this dependecy is not needed.
I build the index with "EXPLICIT_PACKAGE_DEPENDS=yes",
which reduced the number of ports affected alot.
Sadly further work on this general problem has been suspended.
I hoped the current package tools where up to the task,
making this bump obsolete, but I have been prooven wrong.
Absolutely. I don't what to come over as if I'm complaining about ports
I maintain in particular -- it's the general problem of finding ports that
are affected by a shlib bump which I think needs a better solution.
It seems to me that the necessary data to construct an appropriate inverse
dependency graph is simply not extracted anywhere, so port management tools
just don't have the wherewithal they need to solve this problem.
You could, for instance, run ldd(1) against each of the files a port installs
and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or equivalently in the
.tbz package tarball a sorted and uniq'd list of all the shared libraries
linked against. Or you could resolve the shlib filenames back to the ports
that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port
Makefiles. Hmmm The attached script is a bit slow, and it doesn't
cope with linux executables but it shows the general idea. eg:
% ./shlib-ports-needed.sh php5-gd-5.2.10
print/freetype2
graphics/jpeg
x11/libX11
x11/libXau
x11/libXdmcp
x11/libXpm
x11/libxcb
graphics/png
devel/t1lib
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
#!/bin/sh
# @(#) $Id$
#
# Given a pkgname scan all of the files installed by the package,
# and create a list of all of the shlibs linked to by any executables
# or shlibs from that package.
#
PATH=/usr/bin:/bin:/usr/sbin:/sbin ; export PATH
IFS='
' ; export IFS
umask 022
pkgname=${1?'Please supply the name of an installed package'}
lddcmd=""
TMP=$( mktemp -t "$( basename $0 ).XX" )
if [ $? -ne 0 ]; then
echo "$0: FATAL Can't create teporary file"
exit 1
fi
trap "rm $TMP && exit" EXIT INT KILL
for f in $( pkg_info -qLx $pkgname ) ; do
ldd -f "%p\n" $f 2>/dev/null >> $TMP
done
pkglist=$( for f in $( sort -u $TMP ) ; do pkg_info -qW $f ; done | sort -u )
for f in $pkglist ; do
pkg_info -qo $f
done
#
# That's All Folks!
#
signature.asc
Description: OpenPGP digital signature
Re: ports/*/jpeg "Thanks a lot guys"
On Sat, 01 Aug 2009 10:10:17 +0100 Matthew Seaman wrote: > The OP does have a valid point though. I just got an e-mail from > Freshports saying that a bunch of ports I maintain had had > PORTREVISION bumps because of the jpeg update. Which is all fine and > dandy, except that these were the www/p5-RT-* extension modules for > RT. > ... Actually, I think his point was that the ports were bumped too long after the jpeg update, when people had already done the recursive upgrade. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Hallo Matthew Seaman, > The OP does have a valid point though. I just got an e-mail from Freshpo= > rts > saying that a bunch of ports I maintain had had PORTREVISION bumps becaus= > e of > the jpeg update. Which is all fine and dandy, except that these were the= > =20 > www/p5-RT-* extension modules for RT. First of all, they are pure perl: = > there's > no object linkage with the jpeg shlibs at all. Secondly, they have nothi= > ng > to do with manipulating jpeg data in any way, shape or form. One of thei= > r > dependencies links against libjpeg: that's it. This may be, but the port has "libjpeg" as dependency listed. ports/www/p5-RT-Authen-ExternalAuth$ make all-depends-list | grep jpeg /usr/ports/graphics/jpeg ports/www/p5-RT-Extension-SLA$ make all-depends-list | grep jpeg /usr/ports/graphics/jpeg Sorry I had no way to detect if this dependecy is not needed. I build the index with "EXPLICIT_PACKAGE_DEPENDS=yes", which reduced the number of ports affected alot. Sadly further work on this general problem has been suspended. I hoped the current package tools where up to the task, making this bump obsolete, but I have been prooven wrong. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] http://people.freebsd.org/~dinoex/errorlogs/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, 31 Jul 2009 19:36:36 +0200 Erik Trulsson wrote: > On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: > > > > Now that I have finally upgraded my system in full from the last > > mix-up with jpeg, You guys have bumped up every PORTREVISION that > > depends on jpeg "Great real great" Now I get to spend another three > > days fixing up some more packages and rebuilding about 800+ ports. > > > > Thanks a whole lot. > > Nobody is forcing you to rebuild your ports just because the > PORTREVISION was bumped. If everything works fine for you there is > actually no good reason at all to do so. Sorry, but from personal experience in similar situations, sooner or later it will come back to bite you in the ass. Better to use something like: 'portmanager -u -p' now and get it over with than wait until the least opportunistic time arrives for something to fail. Then again, it is your system. -- Jerry ges...@yahoo.com RUGGED: Too heavy to lift. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
Erik Trulsson wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg "Great real great" Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. The OP does have a valid point though. I just got an e-mail from Freshports saying that a bunch of ports I maintain had had PORTREVISION bumps because of the jpeg update. Which is all fine and dandy, except that these were the www/p5-RT-* extension modules for RT. First of all, they are pure perl: there's no object linkage with the jpeg shlibs at all. Secondly, they have nothing to do with manipulating jpeg data in any way, shape or form. One of their dependencies links against libjpeg: that's it. Blanket modification of PORTREVISION for everything that can depend on a shlib which has had an ABI version bump is certainly effective, but it seems too much of a blunt instrument to me. You don't need a revision bump for dependencies that install no ELF format executables, shlibs or similar. Detecting what ports install ELF executables is not too hard -- I submitted ports/129210 which should do the job, although I was thinking more along the lines of factoring out ports that are architecture independent and only building them once on the package build cluster when I submitted that. Needs some work on capturing the output for use by port comitters / maintainers Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, 31 Jul 2009 16:53:16 -0500 "Jeremy Messenger" wrote: > On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson > wrote: > > > On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: > >> > >> Now that I have finally upgraded my system in full from the last mix-up > >> with jpeg, You guys have bumped up every PORTREVISION that depends on > >> jpeg > >> "Great real great" Now I get to spend another three days fixing up some > >> more packages and rebuilding about 800+ ports. > >> > >> Thanks a whole lot. > > > > Nobody is forcing you to rebuild your ports just because the PORTREVISION > > was bumped. If everything works fine for you there is actually no good > > reason at all to do so. > So now the implication becomes that everyone should resort to manual checking of port versions and upgrade each port manually from here on out ?. Because if that is going to happen then eventually someone or a amateur for that matter is going to manually check their ports and come across an update they need and then it will update hand-in-hand every port that depends on libjpeg just to satisfy itself. Am I wrong ? is this not why portupgrade and portmaster were created so this could be done autonomously ? Don't get me wrong but I have been very involved in this upgrade that slipped into my systems from the 19th and it is frustrating when a rather circumvented actions consequences were not well thought out and gets repeated again for a third time. Please don't take this as a list bash or a personal matter, but I believe this needs to be discussed so it could be prevented in the future. Maybe a policy change on library bumps ? that gets more developers involved so the process is less likely to cause administration overhead. Or a policy stating that if your ports lib is bumped you should also bump all PORTREVISIONS that depend on it at the time it is committed ?. That is up for discussion and these are only thoughts but they are thoughts with a new user community in mind. Best regards. I am not on this list: please CC me in your replies. > Yes, but how can you tell if there is newer version? The pkg_version and > pkgversion don't tell you that it's PORTREVISION or actually newer > version. What about when we run 'port* -a'? Took about two weeks to get > PORTREVISION bump isn't right at all. > > Cheers, > Mezz > > > -- > me...@cox.net - m...@freebsd.org > FreeBSD GNOME Team > http://www.FreeBSD.org/gnome/ - gn...@freebsd.org Thanks Mezz -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, Jul 31, 2009 at 2:53 PM, Jeremy Messenger wrote: > On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson > wrote: > > On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: >> >>> >>> Now that I have finally upgraded my system in full from the last mix-up >>> with jpeg, You guys have bumped up every PORTREVISION that depends on >>> jpeg >>> "Great real great" Now I get to spend another three days fixing up some >>> more packages and rebuilding about 800+ ports. >>> >>> Thanks a whole lot. >>> >> >> Nobody is forcing you to rebuild your ports just because the PORTREVISION >> was bumped. If everything works fine for you there is actually no good >> reason at all to do so. >> > > Yes, but how can you tell if there is newer version? The pkg_version and > pkgversion don't tell you that it's PORTREVISION or actually newer version. > What about when we run 'port* -a'? Took about two weeks to get PORTREVISION > bump isn't right at all. > Yes it does. If the version numbers are the same, but the _X number is different, then it's a PORTREVISION change only. 2.4.1_1 vs 2.4.1_2 is a port revision bump. 2.4.1_1 vs 2.4.2 is a version change. X.Y.Z are the PORTVERSION. _A is the PORTREVISION ,B is the PORTEPOCH Giving a total version string of X.Y.Z_A,B -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg "Great real great" Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/*/jpeg "Thanks a lot guys"
On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: > > Now that I have finally upgraded my system in full from the last mix-up > with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg > "Great real great" Now I get to spend another three days fixing up some > more packages and rebuilding about 800+ ports. > > Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports/*/jpeg "Thanks a lot guys"
Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg "Great real great" Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
