Re: freebsd-games: hack needs -fwritable-strings
James Cook wrote: $ uname -a FreeBSD glider 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Tue Dec 11 13:40:40 PST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GLIDER i386 The problem: - Install games/freebsd-games - run hack - Say y when it asks if you're experienced. - Type T for tourist. There will be a bus error. This seems to be caused by line 170 of hack.u_init.c, which attempts to modify a string constant. SOLUTION: Add -fwritable-strings to CFLAGS in hack's Makefile. (There's already a patch that changes that line of the Makefile, so this is easy to change.) the -fwritable-strings option has been deprecated on GCC 3.x and has removed on GCC 4.x. A code modernization is likely to be needed. -- Pietro Cerutti PGP Public Key: http://gahr.ch/pgp signature.asc Description: OpenPGP digital signature
graphviz-2.16.tar.gz Not Found
hi I cannot install [B]graphviz[/B] from ports on my freeBSD 6.2-RELEASE-p9 due to the following errors: # cd /usr/ports/graphics/graphviz # make install clean === Vulnerability check disabled, database not found === Found saved configuration for graphviz-2.16 = graphviz-2.16.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://www.graphviz.org/pub/graphviz/ARCHIVE/. fetch: transfer timed out = Attempting to fetch from http://mirror.inerd.com/FreeBSD/distfiles/graphviz/. fetch: http://mirror.inerd.com/FreeBSD/distfiles/graphviz/graphviz-2.16.tar.gz: Not Found = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/graphviz-2.16.tar.gz: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/ports/graphics/graphviz. *** Error code 1 Stop in /usr/ports/graphics/graphviz. how to solve this problem or where can I download [B]graphviz-2.16.tar.gz[/B] manually ? ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Schmehl wrote:
Some of this has been discussed ad infinitum, but, in an off-list
conversation, I came up with this list of suggested improvements
for port. I'd like to see these things done, but I'm not sure how.
Improve the docs? Create a checklist?
A fairly complete redrafting of the current docs (combine the stuff in
the handbook and the stuff in the porters guide into a ports guide)
is one of the side projects of ports 2.0.
1) You can't build a dependent port and first set the config for
the options that you want. So, when you select sasl in postfix,
you never get the chance to check the saslauthd option, for
example. 2) There's no standard for some of the details of port
building. So, it's entirely up to the port maintainer and the
committer to decide how to build the port. The postfix port
maintainer *could* include a dependency for saslauthd. He chose not
to. He *could* include a note in pkg-message that warns you that
saslauthd needs to be installed as well. He chose not to. His
choices are both reasonable and customary, but they don't serve the
customer well. 3) There's no standard for the format of pkg-plist,
pkg-message or pkg-descr, so port maintainers are free to put
whatever they want in there. There's a customary way of doing it,
but it's not set in stone and variations are found throughout
ports. 4) There's no standard for config files. Do you overwrite?
Do you ignore? Do you create port.conf-sample? port.conf-dist?
port.conf-example? Do you check to see if port.conf is there, and,
if not, copy it to ${LOCALBASE}/etc? ${PREFIX}/etc? 5) There's no
standard for pkg-plist. When is it required? When is it not?
(IOW, what's the maximum number of files you can put in Makefile so
you don't have to create a pkg-plist? Do you use unexec always?
Or only when you want/decide to? Do you just ignore the conf file
and not uninstall it?
All of the above have been adddressed and/or on the agenda for ports
2.0. If you want details contact me, David Southwell or
[EMAIL PROTECTED] since the topic has been more then hashed out
publically and til some results are ready it is not a good idea to do
so again.
I don't know the right answer to these questions, but I think they
need to be answered. I'm willing to volunteer to do some work if
someone will tell me what that work is. Docs? A committee?
Already established in forms of the ports 2.0 team if you want to join
we are always looking for new people.
- --
Aryeh M. Friedman
FloSoft Systems, Java Developer Tools.
http://www.flosoft-systems.com
Developer, not business, friendly.
Free software != Free beer
Blog:
http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHh46yjRvRjGmHRgQRApY/AKCJ6imZ2R0C+Fr1iwuGkPVMheouSwCfZpV7
NU46QLG7bgOkUjLLEhA0KR8=
=CAcR
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: nmap-4.20
Ghirai [EMAIL PROTECTED] 2008-01-07: Just letting you know that nmap 4.52 is out, along with a new frontend. I was wondering when you'll add it to the ports tree. I am working on it. There are a number of big changes (new lua based nmap scripting engine, python based zenmap replacing nmapfe) requiring a lot of work on the nmap ports. -- Daniel Roethlisberger [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Suggested improvements for ports
Some of this has been discussed ad infinitum, but, in an off-list conversation,
I came up with this list of suggested improvements for port. I'd like to see
these things done, but I'm not sure how. Improve the docs? Create a checklist?
1) You can't build a dependent port and first set the config for the options
that you want. So, when you select sasl in postfix, you never get the chance
to check the saslauthd option, for example.
2) There's no standard for some of the details of port building. So, it's
entirely up to the port maintainer and the committer to decide how to build the
port. The postfix port maintainer *could* include a dependency for saslauthd.
He chose not to. He *could* include a note in pkg-message that warns you that
saslauthd needs to be installed as well. He chose not to. His choices are
both reasonable and customary, but they don't serve the customer well.
3) There's no standard for the format of pkg-plist, pkg-message or pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are found
throughout ports.
4) There's no standard for config files. Do you overwrite? Do you ignore? Do
you create port.conf-sample? port.conf-dist? port.conf-example? Do you check
to see if port.conf is there, and, if not, copy it to ${LOCALBASE}/etc?
${PREFIX}/etc?
5) There's no standard for pkg-plist. When is it required? When is it not?
(IOW, what's the maximum number of files you can put in Makefile so you don't
have to create a pkg-plist? Do you use unexec always? Or only when you
want/decide to? Do you just ignore the conf file and not uninstall it?
I don't know the right answer to these questions, but I think they need to be
answered. I'm willing to volunteer to do some work if someone will tell me
what that work is. Docs? A committee?
Suggestions welcomed.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Miro crashes at startup
On Fri, 11 Jan 2008 03:59:26 -0600, Volker Glatz [EMAIL PROTECTED] wrote: Am Freitag 11 Januar 2008 schrieb Aryeh M. Friedman: Thierry Thomas wrote: Le Jeu 10 jan 08 à 12:06:16 +0100, Volker Glatz [EMAIL PROTECTED] écrivait : Hi there, Hello, I installed miro with portinstall miro - not changing any make options. It crashes at startup. Let me know, if you need more informations. Could you please tell me if xulrunner is installed on your machine? And the date of /usr/ports/multimedia/miro/files/patch-platform_gtk-x11_setup.py Such a bug had been reported by lioux, and has been fixed on Dec 14. This also happens if you install boost instead of boost-python... if you install boost with -WITH_PYTHON it works fine what is the reason for boost-python instead of boost? Regards, I had boost installed. Miro complained about it, so I installed boost-phyton. Because you didn't install boost with WITH_PYTHON=yes. Miro requires boost with python support. Cheers, Mezz Volker -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ 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
n 1/11/08, Paul Schmehl [EMAIL PROTECTED] wrote:
Some of this has been discussed ad infinitum, but, in an off-list
conversation,
I came up with this list of suggested improvements for port. I'd like to see
these things done, but I'm not sure how. Improve the docs? Create a
checklist?
:
3) There's no standard for the format of pkg-plist, pkg-message or pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are found
throughout ports.
There is a standard format for pkg-plist. Which is documented in the
port's handbook.
pkg-descr does have a standard format:
descr
WWW: projects web site
pkg-message format is left to the maintainer.
The only requirement for pkg-descr and pkg-message is that it should
be able to display on an 80 column screen without the lines wrapping.
4) There's no standard for config files. Do you overwrite? Do you ignore?
Do
you create port.conf-sample? port.conf-dist? port.conf-example? Do you
check
to see if port.conf is there, and, if not, copy it to ${LOCALBASE}/etc?
${PREFIX}/etc?
There is a standard for config files, and is documented in the porters handbook.
The port maintainer should install configuration files so that they
don't overwrite existing configuration files.
The way that most ports take is by patching the src to install the
standard config files with an extension (currently we use -sample,
-dist, -orig, or -example). Then the port should check for the
existance of the config file, and install one if it doesn't exist.
When the port is uninstalled, it compares the config file with the
default config file, and only removes the config file if they are the
same.
NOTE: should standardize a default extension.
When there are a large number of configuration files, a few ports
install the default configuration files into an alternate directory
(i.e PREFIX/share/example/portname), and then copy them to
PREFIX/etc when they don't exist. On deinstall, they compare the
config file with the default config file, and only remove the config
files if they are the same.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOW-TO get Flash7 working!
Quoting Chuck Robey [EMAIL PROTECTED] (from Thu, 10 Jan 2008 21:05:16 -0500): I actually got the linux flash9 working. Why didn't I post it, put in a patch? Because one of the main reasons that it doesn't work now is the insane way that much Linux libraries are installed. If folks would honor Would you mind telling us how, so that we understand the problem? hier(7) then all linux libs would go into /usr/compat/usr/lib, but instead, many linux ports (including browsers, believe me) install into $(PREFIX)/lib/libsubdir. This means every single linux app that uses linux libs hsa to be run with a shell wrapper, artificially extending the LD_LIBRARY_PATH. Since no porter of an app installing libs knows all the ports that might use their libs, random breakages are the rule of the day, to say nothing of the egregious harm to security this kind of strategy causes. It's a big reason why the flash things don't work. Want proof? Go use the linux ldd to see just how long the list of libraries is, that those extensions use, then you'll begin to see. Not all those libs are browser products, either. Have fun trying to get a wrapper to work there. I volunteered to fix this situation all myself, if only the ports management would give me written agreement that the strategy I decry is in fact bad software practice, so that I may point to that document to port authors, when I ask for permission to edit their work. Ports management hasn't seen fit to reply, or at least, I haven't seen it if they did. I don't intend to force anyone, but without having ports mangement backing, I am NOT going to have this argument with every porter, no way. I tried that once, and at least one fellow told me he thought that requiring every linux application to have it's own wrapper was the cleaner way to go. Huh, if that's so, then I guess I should be stopped anyhow. You think that way? I think you are referring to me here. I think the important part to understand my opinion to install end-user applications into PREFIX instead of LINUXPREFIX (note: linux library ports _have_ to go to LINUXBASE) is missing here. No user shall have subdirs of LINUXPREFIX in his path. This would open up Pandorra's box. A clean way to achieve this is to have something in prefix which calls the linux program. This can be a symlink or a wrapper in PREFIX. If you install parts of a port into LINUXPREFIX and a link/wrapper in PREFIX (or more generic: if you have 2 different prefixes in a port), you have to do some ports-magic. If you install the port in a sub-directory in PREFIX and add a wrapper in the PREFIX/bin, you don't have to do ports-magic. Writting a wrapper is easy, porting linux programs is already hard, and the ports-magic is something which can result in tears when not done correctly. Also don't underestimate the pitfalls with accessing linux libs in the linuxulator when they are in LINUXPREFIX. The best solution would be to rewrite the linux run time linker and get rid of the linux default one, but this is not really a pragmatic solution, we will get hit by problems as soon as something important changes in the linux run time linker, and we don't have the man-power to permanently keep up. The current way of handling the linuxulator things in the ports is not the ideal way, it is a pragmatic way. It's weighting the good and the bad things of the different ways to get it working, and trying to do it in a way which is beneficial to most people. Bye, Alexander. -- Absence makes the heart grow fonder. -- Sextus Aurelius http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
On Fri, Jan 11, 2008 at 06:40:35PM +0100, Guido Falsi wrote: I think that too much formalization in the porting rules would harm the system. That seems to have been the community consensus in the past. Nevertheless, the PH could use some improvement. Most of what I've tried to put in there is here's what we recommend as the preferred practice. There's not much you can't do this -- most of that deals with things that e.g. break INDEX or otherwise wreak havoc. mcl ___ 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
--On Friday, January 11, 2008 10:34:15 -0600 Scot Hetzel [EMAIL PROTECTED]
wrote:
n 1/11/08, Paul Schmehl [EMAIL PROTECTED] wrote:
Some of this has been discussed ad infinitum, but, in an off-list
conversation, I came up with this list of suggested improvements for port.
I'd like to see these things done, but I'm not sure how. Improve the docs?
Create a checklist?
:
3) There's no standard for the format of pkg-plist, pkg-message or pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are found
throughout ports.
There is a standard format for pkg-plist. Which is documented in the
port's handbook.
Is there a description of when to use unexec and when not to? Is there an
explanation of what to do with conf files? (Do you leave them alone? Compare
them to the sample file and delete only if they're the same? Delete always?)
What's the limit on the number of files you can put in PLIST_FILES?
Directories in PLIST_DIRS? Is there any requirement to use pkg-plist?
When do you use @dirrm as opposed to @dirrmtry? How are conditionals handled
in pkg-plist?
pkg-descr does have a standard format:
descr
WWW: projects web site
What content goes in pkg-descr? Is it required? Optional? Is WWW: required?
Optional?
pkg-message format is left to the maintainer.
The only requirement for pkg-descr and pkg-message is that it should
be able to display on an 80 column screen without the lines wrapping.
Yes, but is it required? Not required? What content goes in it? These are
all questions left to the maintainer, and a brief analysis of ports shows a
great deal of inconsistency in their usage. Many ports have no pkg-message at
all. Is it optional? If an OPTION must be set on a dependency port, are you
required to mention that in pkg-message? What information is required? What
is optional?
4) There's no standard for config files. Do you overwrite? Do you ignore?
Do you create port.conf-sample? port.conf-dist? port.conf-example? Do you
check to see if port.conf is there, and, if not, copy it to ${LOCALBASE}/etc?
${PREFIX}/etc?
There is a standard for config files, and is documented in the porters
handbook.
The port maintainer should install configuration files so that they
don't overwrite existing configuration files.
And name them now? -sample? -dist? -example? -orig? And what about
removal? When you deinstall the port, do you remove the conf file? Remove
only if it's unaltered? Ignore it entirely?
The way that most ports take is by patching the src to install the
standard config files with an extension (currently we use -sample,
-dist, -orig, or -example). Then the port should check for the
existance of the config file, and install one if it doesn't exist.
When the port is uninstalled, it compares the config file with the
default config file, and only removes the config file if they are the
same.
NOTE: should standardize a default extension.
Precisely.
When there are a large number of configuration files, a few ports
install the default configuration files into an alternate directory
(i.e PREFIX/share/example/portname), and then copy them to
PREFIX/etc when they don't exist. On deinstall, they compare the
config file with the default config file, and only remove the config
files if they are the same.
Is this how it should always be done?
This is my point. On many of these criteria there is an uncomfortable amount
of squishyness so that port maintainers, *especially* new ones, are unsure
what the right thing to do is. The porters handbook seems written from the
standpoint of a guide more than a manual. IOW, it advises rather than
instructs. I think that needs to change, because it would bring more
consistency to bear on ports and eliminate some of the questions that get
repeatedly asked because folks are unsure of the answer.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
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
Mark Linimon wrote: On Fri, Jan 11, 2008 at 06:40:35PM +0100, Guido Falsi wrote: I think that too much formalization in the porting rules would harm the system. That seems to have been the community consensus in the past. Nevertheless, the PH could use some improvement. Most of what I've tried to put in there is here's what we recommend as the preferred practice. There's not much you can't do this -- most of that deals with things that e.g. break INDEX or otherwise wreak havoc. Obviously some rules are needed to maintain the structure, I meant no attack to that. I simply wanted to say that I agree with the policy stated above. Putting rules like strict limiting numbers to items or the like would be against the ports logic. I think. -- Guido Falsi [EMAIL PROTECTED] ___ 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
On Fri, 11 Jan 2008 09:29:14 -0600 Paul Schmehl wrote:
Seems that some answers (well, maybe some not obvious, some lack
examples, etc.) are already at the Porters Handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html
Some of this has been discussed ad infinitum, but, in an off-list
conversation, I came up with this list of suggested improvements for
port. I'd like to see these things done, but I'm not sure how.
Improve the docs? Create a checklist?
1) You can't build a dependent port and first set the config for the
options that you want. So, when you select sasl in postfix, you never
get the chance to check the saslauthd option, for example.
2) There's no standard for some of the details of port building. So,
it's entirely up to the port maintainer and the committer to decide
how to build the port. The postfix port maintainer *could* include a
dependency for saslauthd. He chose not to. He *could* include a note
in pkg-message that warns you that saslauthd needs to be installed as
well. He chose not to. His choices are both reasonable and
customary, but they don't serve the customer well.
I'd say that there is a way to handle this one: PR. Post a PR with
patches to a current port. If maintainer abandoned the patches you may
file a PR to create a new port (ex. a slave one) which you will
maintain.
3) There's no standard for the format of pkg-plist, pkg-message or
pkg-descr, so port maintainers are free to put whatever they want in
there. There's a customary way of doing it, but it's not set in stone
and variations are found throughout ports.
At those cases which needs standartization (i.e. http section at
pkg-descr) it exists. And I don't see much harm if the rest is not
standarized. Can you show an examples when it hurts?
4) There's no standard for config files. Do you overwrite? Do you
ignore? Do you create port.conf-sample? port.conf-dist?
port.conf-example? Do you check to see if port.conf is there, and, if
not, copy it to ${LOCALBASE}/etc? ${PREFIX}/etc?
5) There's no standard for pkg-plist. When is it required? When is
it not? (IOW, what's the maximum number of files you can put in
Makefile so you don't have to create a pkg-plist? Do you use unexec
always? Or only when you want/decide to? Do you just ignore the conf
file and not uninstall it?
I don't know the right answer to these questions, but I think they
need to be answered. I'm willing to volunteer to do some work if
someone will tell me what that work is. Docs? A committee?
The best way is to enhance the Porters Handbook. Take a topic, create
patches, send them to the list, discuss and then send a PR with
patches. That would be great. BTW, thanks for taking care of it.
Suggestions welcomed.
WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve
___
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
Paul Schmehl wrote: Is this how it should always be done? This is my point. On many of these criteria there is an uncomfortable amount of squishyness so that port maintainers, *especially* new ones, are unsure what the right thing to do is. The porters handbook seems written from the standpoint of a guide more than a manual. IOW, it advises rather than instructs. I think that needs to change, because it would bring more consistency to bear on ports and eliminate some of the questions that get repeatedly asked because folks are unsure of the answer. I think that too much formalization in the porting rules would harm the system. We need standards, but we can't cover every single case. There will be ported apps which can't fit in a too strict set of rules. Also stricter rules will cover less and less special cases, creating exceptions. Porting techniques need to be flexible. This is, obviously, just my own opinion. -- Guido Falsi [EMAIL PROTECTED] ___ 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
Guido Falsi wrote: Mark Linimon wrote: On Fri, Jan 11, 2008 at 06:40:35PM +0100, Guido Falsi wrote: I think that too much formalization in the porting rules would harm the system. That seems to have been the community consensus in the past. Nevertheless, the PH could use some improvement. Most of what I've tried to put in there is here's what we recommend as the preferred practice. There's not much you can't do this -- most of that deals with things that e.g. break INDEX or otherwise wreak havoc. Obviously some rules are needed to maintain the structure, I meant no attack to that. I simply wanted to say that I agree with the policy stated above. Putting rules like strict limiting numbers to items or the like would be against the ports logic. I think. This thread seems like one we covered in the recent past. I have held off until now, but I think people are missing the perspectives of many port maintainers, maybe most. Those I mean are subject experts that are not computer scientists. I am a biochemist, but I maintain two ports (neither a biggie). We, and I am so bold as to speak for this group, see the need for standards, wish the ports system was perfect, but also are very sensitive to the doctrine of perfect as the enemy of good. We write ports because of convenience, by and large. Heavy requirements on port structure will just cause us to quit writing our ports, or cause us to keep them in house. In chemistry there is something called transition state theory. It posits that the rate of a reaction (here the likelihood I will write a port for a piece of software I use) is directly proportional to the inverse of the energetic barrier height between reactants and products. If you raise the barrier height by putting hard and fast requirements that are much more onerous than currently exist, you will see the rate of new port formation for other than biggie software fall dramatically. IMO. Please don't let the search for computer science elegance break the ports system. FreeBSD ports is the one place where the developers and the users meet on the street. Bud Dodson PS, by similar reasoning, I think the Ports 2.0 project is a loser in the real world. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ 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
--On Friday, January 11, 2008 12:23:31 -0600 Mark Linimon [EMAIL PROTECTED] wrote: On Fri, Jan 11, 2008 at 11:10:45AM -0600, Paul Schmehl wrote: The porters handbook seems written from the standpoint of a guide more than a manual. That's something that I was going to work on, um, last year :-) We need both. Right now we have this hybrid which isn't a completely satisfactory solution for either one. This is historical; it kind of grew out of an initial short how-to document, then, as new things were stuffed into the ports infrastructure, there was no better place to document them. The quick porting text should turn into a guide; the slow porting text should become the reference. I like this idea. The problem for new porters is that a brief skim of the how to leaves out a lot of details that become important once you actually start creating that first port. Perhaps the right way to approach this is a guide that links to a reference doc? The guide covers the basic rules (if you're going to do this, do it this way, if you're not going to do that, you need to do this instead) and then the reference provides both links and examples to show how something is done. I agree we shouldn't formalize it too much, but I *do* think some things should be standardized. For example, the default conf file should have a standardized name throughout, either -sample or -dist or -example or something, and that should be followed throughout. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOW-TO get Flash7 working!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Leidinger wrote: Quoting Chuck Robey [EMAIL PROTECTED] (from Thu, 10 Jan 2008 21:05:16 -0500): I actually got the linux flash9 working. Why didn't I post it, put in a patch? Because one of the main reasons that it doesn't work now is the insane way that much Linux libraries are installed. If folks would honor Would you mind telling us how, so that we understand the problem? hier(7) then all linux libs would go into /usr/compat/usr/lib, but instead, many linux ports (including browsers, believe me) install into $(PREFIX)/lib/libsubdir. This means every single linux app that uses linux libs hsa to be run with a shell wrapper, artificially extending the LD_LIBRARY_PATH. Since no porter of an app installing libs knows all the ports that might use their libs, random breakages are the rule of the day, to say nothing of the egregious harm to security this kind of strategy causes. It's a big reason why the flash things don't work. Want proof? Go use the linux ldd to see just how long the list of libraries is, that those extensions use, then you'll begin to see. Not all those libs are browser products, either. Have fun trying to get a wrapper to work there. I volunteered to fix this situation all myself, if only the ports management would give me written agreement that the strategy I decry is in fact bad software practice, so that I may point to that document to port authors, when I ask for permission to edit their work. Ports management hasn't seen fit to reply, or at least, I haven't seen it if they did. I don't intend to force anyone, but without having ports mangement backing, I am NOT going to have this argument with every porter, no way. I tried that once, and at least one fellow told me he thought that requiring every linux application to have it's own wrapper was the cleaner way to go. Huh, if that's so, then I guess I should be stopped anyhow. You think that way? I think you are referring to me here. I think the important part to understand my opinion to install end-user applications into PREFIX instead of LINUXPREFIX (note: linux library ports _have_ to go to LINUXBASE) is missing here. In fact, I have never been at all good at remembering names, to the point that I no longer even try. I haven't the faintest idea (even now) if it was you or not. If it pleases you, though, that's fine, assume away. I don't think I was insulting, I have made enough of an ass of myself in the past to realize the folly of being sarcastic (it always comes back to bite you). No user shall have subdirs of LINUXPREFIX in his path. This would open up Pandorra's box. OK, need to stop you here. I don't know what that LINUXPREFIX item is. I just grepped for it in /usr/ports subdirs Mk, emulators, and www (recursive one), and even did an apropos. I did a bit of googling and found a LINUXPREFIX in some Linux docs, is that the one you're referring to? What's it mean, how's it used? Regardless, please, could you explain why it would open up Pandora's Box? Maybe if I could have a better handle on what it is, I might not ask that question, but I can't, so I'm asking. One item that some might not know: most unixes have a strong bias towards installing everything into /usr/bin or /usr/lib. Many Linux boxes don't even have a /usr/local, or opt, or whatever. Much Linux software makes the assumption that it's using a prefix of /usr. I hate this myself, I MUCH more like FreeBSD's way of doing things, but I can have my cake and eat it too, if Linux software is installed into /compat/linux/usr/bin (and lib, etc), I get the separation as far as FreeBSD is concerned, but Linux software is fooled into obeying their abhorrent lack of separation. Real nice. [Man, your mail is huge, I would have preferred to make it decide things in smaller bits, but I guess not.] Continuing ... A clean way to achieve this is to have something in prefix which calls the linux program. This can be a symlink or a wrapper in PREFIX. If you install parts of a port into LINUXPREFIX and a link/wrapper in PREFIX (or more generic: if you have 2 different prefixes in a port), you have to do some ports-magic. If you install the port in a sub-directory in PREFIX and add a wrapper in the PREFIX/bin, you don't have to do ports-magic. OK. Ab initio, I have always felt that using wrappers was a tacky way to do things. Not that it wasn't sometimes the only available way to go, but certainly to be avoided. I also have always felt that screwing with LD_LIBRARY_PATH, as your wrappers would need to do, is a security problem, which again might sometimes be the best way to go, but not ever the first choice. This is only part of my argument, though (I would be embarrassed if my argument was only based upon my prejudices). The larger real problem is, some ports install libs, and do not know what possible executables might need to have
Re: Suggested improvements for ports
On 1/11/08, Paul Schmehl [EMAIL PROTECTED] wrote:
--On Friday, January 11, 2008 10:34:15 -0600 Scot Hetzel [EMAIL PROTECTED]
wrote:
n 1/11/08, Paul Schmehl [EMAIL PROTECTED] wrote:
Some of this has been discussed ad infinitum, but, in an off-list
conversation, I came up with this list of suggested improvements for port.
I'd like to see these things done, but I'm not sure how. Improve the docs?
Create a checklist?
:
3) There's no standard for the format of pkg-plist, pkg-message or
pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are
found
throughout ports.
There is a standard format for pkg-plist. Which is documented in the
port's handbook.
Is there a description of when to use unexec and when not to? Is there an
explanation of what to do with conf files? (Do you leave them alone? Compare
them to the sample file and delete only if they're the same? Delete always?)
The man page for pkg_create has some information on when to use
@unexec in your pkg-plist. I have seen @exec/@unexec for
installation/removal of configuration files, creation/deletion of
links and creation of empty directories.
The information on configuration files is in the porter's handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/plist-config.html
You only delete configuration files when they are the same as the sample files.
What's the limit on the number of files you can put in PLIST_FILES?
Directories in PLIST_DIRS? Is there any requirement to use pkg-plist?
According to the porter's handbook, it mentions when the port installs
a handfull of files.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-desc.html#AEN99
When your using PLIST_FILES, PLIST_DIRS, there is no need to use
pkg-plist. But if your port needs to use @dirrmtry, @exec, @unexec,
... then you should be using pkg-plist.
When do you use @dirrm as opposed to @dirrmtry? How are conditionals handled
in pkg-plist?
You use @dirrm when only your port installs files into a directory
that it has created. You use @dirrmtry when your port installs files
into a directory that was created by another port or another port
installs files into a directory that your port created.
pkg-descr does have a standard format:
descr
WWW: projects web site
What content goes in pkg-descr? Is it required? Optional? Is WWW: required?
Optional?
This link tells you what is required in pkg-descr (pkg-descr is
required), it also explains when WWW: should be used.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-desc.html#AEN85
pkg-message format is left to the maintainer.
The only requirement for pkg-descr and pkg-message is that it should
be able to display on an 80 column screen without the lines wrapping.
Yes, but is it required? Not required? What content goes in it? These are
all questions left to the maintainer, and a brief analysis of ports shows a
great deal of inconsistency in their usage. Many ports have no pkg-message at
all. Is it optional? If an OPTION must be set on a dependency port, are you
required to mention that in pkg-message? What information is required? What
is optional?
pkg-message is optional. It's use is to provide additional
information that needs to be done after the port has been installed
and couldn't be accomplished using the pkg-install script.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/pkg-files.html#PORTING-MESSAGE
4) There's no standard for config files. Do you overwrite? Do you ignore?
Do you create port.conf-sample? port.conf-dist? port.conf-example? Do
you
check to see if port.conf is there, and, if not, copy it to
${LOCALBASE}/etc?
${PREFIX}/etc?
There is a standard for config files, and is documented in the porters
handbook.
The port maintainer should install configuration files so that they
don't overwrite existing configuration files.
And name them now? -sample? -dist? -example? -orig? And what about
removal? When you deinstall the port, do you remove the conf file? Remove
only if it's unaltered? Ignore it entirely?
The way that most ports take is by patching the src to install the
standard config files with an extension (currently we use -sample,
-dist, -orig, or -example). Then the port should check for the
existance of the config file, and install one if it doesn't exist.
When the port is uninstalled, it compares the config file with the
default config file, and only removes the config file if they are the
same.
NOTE: should standardize a default extension.
Precisely.
When there are a large number of configuration files, a few ports
install the default configuration files into an alternate directory
(i.e PREFIX/share/example/portname), and then copy them to
PREFIX/etc
Re: Suggested improvements for ports
On Fri, Jan 11, 2008 at 11:10:45AM -0600, Paul Schmehl wrote: The porters handbook seems written from the standpoint of a guide more than a manual. That's something that I was going to work on, um, last year :-) We need both. Right now we have this hybrid which isn't a completely satisfactory solution for either one. This is historical; it kind of grew out of an initial short how-to document, then, as new things were stuffed into the ports infrastructure, there was no better place to document them. The quick porting text should turn into a guide; the slow porting text should become the reference. Of course, I say this, without the cycles to work on it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
On 13/12/2007, Brian [EMAIL PROTECTED] wrote: I just wonder if you asked the general population, whether they'd rather have ports or packages, I bet most would vote for packages, aside from those that actually like watching the compilation output fly by. I do like to watch it but in addition I always like to compile my own binaries etc. rather than using something thats precompiled and limited to how the compiler compiled it. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limitations of Ports System
--- Chris [EMAIL PROTECTED] wrote: On 13/12/2007, Brian [EMAIL PROTECTED] wrote: I just wonder if you asked the general population, whether they'd rather have ports or packages, I bet most would vote for packages, aside from those that actually like watching the compilation output fly by. I do like to watch it but in addition I always like to compile my own binaries etc. rather than using something thats precompiled and limited to how the compiler compiled it. Chris I change options in the mplayer Makefile to include twolame and mencoder in the build because that way you get more codecs available for mencoder. Also, MySQL has WITH_OPENSSL=yes in the make, and in PHP make config, I select Build Apache module. Also I have the following options on in /etc/make.conf. CFLAGS= -O -pipe# Optimize general builds COPTFLAGS= -O -pipe # Optimize kernel builds NO_PROFILE= # Only need to uncomment this line, no options Finally, as a rule I install the latest patched up version of stable 6.x from this optimised build (build once on a master cvs/build server). Dont know how many other people do this, but I definately prefer ports over packages. Cheers, Tim. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ 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
I'm going to try to combine your two posts so that I can answer in one, my apologies if I scramble something. Paul Schmehl wrote: Some of this has been discussed ad infinitum, but, in an off-list conversation, I came up with this list of suggested improvements for port. I'd like to see these things done, but I'm not sure how. Improve the docs? Create a checklist? 1) You can't build a dependent port and first set the config for the options that you want. So, when you select sasl in postfix, you never get the chance to check the saslauthd option, for example. Portmaster actually does a depth-first traversal of the dependency tree which allows you to do this. That said, I think there are 2 additions it would be nice to make to the OPTIONS framework to aid the situation you describe. One would be having OPTIONS inherit default settings from the environment, so that if the user has a global option set, that same option in a port's OPTIONS block always comes up the way the user specified, unless ... The other thing that would be really great is something like super-options that a port could set that would enforce that option in the dependent ports (or generate an error if in conflict with the user's global options). Bonus points if this super-option could trigger the rebuild of an existing port/package to get the stuff it needs. With the super-option idea, if you MUST have saslauthd support in order for something to work (and I'm just picking up on your example, no idea of this specific case is meaningful or not) then the right thing would happen all the way down the chain. This would of course require some large amount of coordination between port authors, but a lot of the standardization you'd need is already de facto. 2) There's no standard for some of the details of port building. Now you're mixing in developer issues with user issues. The user should never have to see the details you're describing here, although if (as I gather from later in the thread) your desire is improved how to docs for ports creation, than I support that goal. it's entirely up to the port maintainer and the committer to decide how to build the port. The postfix port maintainer *could* include a dependency for saslauthd. He chose not to. He *could* include a note in pkg-message that warns you that saslauthd needs to be installed as well. He chose not to. His choices are both reasonable and customary, but they don't serve the customer well. Now here you have to be careful. The way we handle this problem is for those who want/need saslauthd-related postfix to create a postfix-saslauthd version, and handle that support themselves. Bonus points if you can do it as a slave port, but that isn't always the case. Please note, I'm not speaking theoretically here, I've been on both sides of this issue, and so (modulo the prospect of user confusion with N * M different varieties of the same port) the system works. I should also point out that I've had my arm twisted by users to support things in my ports (particularly pine/alpine) that I cannot test for myself (particularly maildir) and so I have done so with the caveat that support for those features _must_ come from the community, or I'll rip them out of the port the first time they break something. This method also works. :) 3) There's no standard for the format of pkg-plist, This has already been covered, but for the record you're wrong about that. pkg-message or pkg-descr, so port maintainers are free to put whatever they want in there. There are rough guidelines (portlint will prod you on both of those, especially pkg-descr) but you're right, no hard and fast rules. I don't remember the latin version, but there is a very old saying to the effect that the one doing the work gets to decide how the work gets done. Guidelines are good here, cookie-cutter approaches don't scale to 18k+ ports. There's a customary way of doing it, but it's not set in stone and variations are found throughout ports. You (pl) need to wrap your head around the fact that this is, and always will be the status quo. If you want rigid rules, go create your own ports system. What's the limit on the number of files you can put in PLIST_FILES? Directories in PLIST_DIRS? Is there any requirement to use pkg-plist? Don't take this the wrong way, but why do you care? If you are asking because you want to write a port, it's a reasonable question, and should probably be given a more thorough treatment in the handbook. However, this precisely the kind of thing for which community takes on real meaning. If you get confused by this, just send a message to the list. I am trying to port FUBAR-1.23, and I'm wondering if and you will generally get at least one answer. Hopefully if you get more than one, they won't conflict. :) When do you use @dirrm as opposed to @dirrmtry? That's an easy one. If the directory might have
