Re: Do we still need portmap(8)?
On (2002/10/09 22:03), Terry Lambert wrote: The other problem with an mtree.obsolete is that it assumes the the upgrade process completes successfully. This doesn't mean that it completes without an error in the upgrade process, it means that the resulting system functions. Why not just let Warner (or whoever) make this solution available and see how it flies? People like you and me who have our own simple and effective ways of pruning stale files can just ignore it or hack it out. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Sheldon Hearn wrote: On (2002/10/09 22:03), Terry Lambert wrote: The other problem with an mtree.obsolete is that it assumes the the upgrade process completes successfully. This doesn't mean that it completes without an error in the upgrade process, it means that the resulting system functions. Why not just let Warner (or whoever) make this solution available and see how it flies? It was discussed already, the last 3 times this topic came up. I believe that the only inoffensive thing that everyone could agree to was: do it however you want, as long as it requires a special (non-default) target to make it do its thing. No one wanted a make install or make installworld or whatever deleting things, especially if it failed. People like you and me who have our own simple and effective ways of pruning stale files can just ignore it or hack it out. I do it manually, just like everyone else. Normally, I build a world, mount the image read-only, and do a full install onto a pingpong partition via NFS, which buys me a clean install, and the ability to go back to the previous root partition, if the new image is too broken to use. I used to have an extra target for /bin/sysinstall to be created on the CDROM image, so that I could do a full upgrade via NFS from a CDROM image (instead of booting from one, particularly on machines that didn't netboot and had no CDROM -- read: appliances), but that doesn't work if you have to actually delete files for things to not break on you (the source of the current controversy: stale files not removed). Personally, I have absolutley no objection to a mtree stale file removal script. I just think it will be nearly impossible to maintain... and if it's not active by default, it's not going to stop the people who post about problems, especially problems with ports. And since it *can't* be active by default... catch-22. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Wednesday 09 October 2002 17:00, Terry Lambert wrote: Danny J. Zerkel wrote: And a list of files to delete would have saved many emails about the GCC being broken when the old headers just needed to be deleted. No, it wouldn't. The same people who failed to read the mailing list, and see the first time the problem came up, and was solved, would fail to read the file. The information was available after the first time the problem was successfully and publically addressed. Sigh... there should be a file listing incompatible files that is part of the source tree. Every file in this list would be deleted as a pre-install step. Perl would not have been in this list because it was not incompatible. But the old C++ headers clearly were. There have no doubt been other instances of incompatible files in the installation or examples of files moving. It will happen to any software system and should be accounted for in the installation mechanism. I challenge you to contact everyone who has posted complaining about the stale header file problem in the last 6 months, and ask them what resources they looked to for a solution, before they contacted the mailing list. I will be incredibly surprised if you find that they have any single README or other file in common, where such information could have been placed. If you *do* find such a file, then you should create a patch, so that there will be no more postings of the question by users as they run into it. The reasons volunteers automate processes are (1) for their own use, (2) to advocate something, or (3) to get other people to shut up. The reasons the topic of automating this process keep coming up are the same; I would say that 90% of the people involved in the discussion (including myself) are in camp #3. Yes, it would be nice if this were automatic, but not if it screws up the ability to run perl scripts (as one example). If you want to address it systematically, then what you can do *right now* is cause a file containing a build identifier to be installed as part of the install world or install from CDROM process that will allow the current system to be recreated. A delta management system is only as good as the timestamp from which the deltas are managed, relative to the current timestamp. Personally, I suggest a file /etc/BUILD be created to contain the CVS tag and a timestamp indicating the checkout time, created as part of the build process (maybe the tag from the output of a CVS stat on the Makefile in /usr/src, processed to deal with sticky tags, and the date stamp on the file itself, otherwise). Yuck. Let's NOT not use CVS (Cantakerous Version Scrambler) tags. Everything else can be hung off that. -- Terry Danny [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Danny J. Zerkel wrote: Sigh... there should be a file listing incompatible files that is part of the source tree. Every file in this list would be deleted as a pre-install step. Perl would not have been in this list because it was not incompatible. But the old C++ headers clearly were. There have no doubt been other instances of incompatible files in the installation or examples of files moving. It will happen to any software system and should be accounted for in the installation mechanism. 1) It has to be a post-install, in case the install fails, part way through. 2) It has to be optional: the user has to specifically ask for the deletion; that way, most of us can ignore it. 3) Feel free to get together with Warner Losh on this, and submit the code. Personally, I suggest a file /etc/BUILD be created to contain the CVS tag and a timestamp indicating the checkout time, created as part of the build process (maybe the tag from the output of a CVS stat on the Makefile in /usr/src, processed to deal with sticky tags, and the date stamp on the file itself, otherwise). Yuck. Let's NOT not use CVS (Cantakerous Version Scrambler) tags. Feel free to use whatever you want, so long as the value can be used as an input to a process which will result in the binaries for the system being recreated identically, except for date stamps. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Monday 07 October 2002 21:05, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2002-10-07 15:14, Archie Cobbs [EMAIL PROTECTED] wrote:
: Anything that gets overwritten during the normal install process
: is already taken care of. We're just trying to get rid of files
: which are not installed by 'make installword' but used to be once.
:
: I.e., if a file is not installed by 'make installworld' then by
: definition it's not required for a correctly functioning system.
:
: This might cause problems with ports that ``overwrite'' base-system
: files. I hate ports the idea of ports writing anything outside of
: ${LOCALBASE}, but we already have some of those IIRC.
Yes. Clearly, there are some files that should always be deleted
(stale binaries and header files), some files that should often be
deleted (those things replaced by ports under the same path, for
example), and some things we'd want to the user to removed (eg,
libfoo.so.N-1)
Warner
And a list of files to delete would have saved many emails about the
GCC being broken when the old headers just needed to be deleted.
Danny
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Danny J. Zerkel wrote: And a list of files to delete would have saved many emails about the GCC being broken when the old headers just needed to be deleted. No, it wouldn't. The same people who failed to read the mailing list, and see the first time the problem came up, and was solved, would fail to read the file. The information was available after the first time the problem was successfully and publically addressed. I challenge you to contact everyone who has posted complaining about the stale header file problem in the last 6 months, and ask them what resources they looked to for a solution, before they contacted the mailing list. I will be incredibly surprised if you find that they have any single README or other file in common, where such information could have been placed. If you *do* find such a file, then you should create a patch, so that there will be no more postings of the question by users as they run into it. The reasons volunteers automate processes are (1) for their own use, (2) to advocate something, or (3) to get other people to shut up. The reasons the topic of automating this process keep coming up are the same; I would say that 90% of the people involved in the discussion (including myself) are in camp #3. Yes, it would be nice if this were automatic, but not if it screws up the ability to run perl scripts (as one example). If you want to address it systematically, then what you can do *right now* is cause a file containing a build identifier to be installed as part of the install world or install from CDROM process that will allow the current system to be recreated. A delta management system is only as good as the timestamp from which the deltas are managed, relative to the current timestamp. Personally, I suggest a file /etc/BUILD be created to contain the CVS tag and a timestamp indicating the checkout time, created as part of the build process (maybe the tag from the output of a CVS stat on the Makefile in /usr/src, processed to deal with sticky tags, and the date stamp on the file itself, otherwise). Everything else can be hung off that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Danny And a list of files to delete would have saved many emails Danny about the GCC being broken when the old headers just needed Danny to be deleted. We could add 'rm -rf /usr/include/*' at a suitable point inside the installworld target. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
At 3:09 PM -0600 10/9/02, Lyndon Nerenberg wrote: Danny And a list of files to delete would have saved many emails Danny about the GCC being broken when the old headers just needed Danny to be deleted. We could add 'rm -rf /usr/include/*' at a suitable point inside the installworld target. Installers should not be blindly removing entire directory structures. It would be much friendlier to simply move them out of the way, in case there happens to be an important (to the user) file inside that directory tree. Or maybe tar.gz them up, if you're concerned about disk space or inodes. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Garance A Drosihn writes: We could add 'rm -rf /usr/include/*' at a suitable point inside the installworld target. Installers should not be blindly removing entire directory structures. The only things that live under /usr/include are those owned by the system's install target, therefore it can do what it likes with that part of the tree. /usr/include should never contain files that do not correspond to the system's current build environment, and any files pertaining to the current build environment will be installed by the install target. There's no conflict here; anything that stops working after a make install scrubs /usr/include is itself broken. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
At 2:00 PM -0700 10/9/02, Terry Lambert wrote: Danny J. Zerkel wrote: And a list of files to delete would have saved many emails about the GCC being broken when the old headers just needed to be deleted. No, it wouldn't. The same people who failed to read the mailing list, and see the first time the problem came up, and was solved, would fail to read the file. The information was available after the first time the problem was successfully and publically addressed. Please note that Danny was replying to Warner's suggestion. What Warner said was: =Yes. Clearly, there are some files that should always be =deleted (stale binaries and header files), some files that =should often be deleted (those things replaced by ports =under the same path, for example), and some things we'd =want to [ask] the user to removed (eg, libfoo.so.N-1) The fact that it is a list of files does not mean that it is only useful if a human being reads the list. We can have a list of files, and have a PROGRAM which reads that list and processes it. Ie, some files in that list would ALWAYS be deleted ... while for SOME other files we (via the program) would ask the user if they wanted those files to be removed. I think most of us realize that we need a solution which can be automatically executed as part of every installworld or mergemaster run. The debate is over the most reasonable method of doing that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: p05111701b9ca84c308c3@[128.113.24.47] Garance A Drosihn [EMAIL PROTECTED] writes: : I think most of us realize that we need a solution which can be : automatically executed as part of every installworld or mergemaster : run. The debate is over the most reasonable method of doing that. My suggestion would work, and would be a viable solution, so far the only one presented in this whole silly thread. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
M. Warner Losh wrote: In message: p05111701b9ca84c308c3@[128.113.24.47] Garance A Drosihn [EMAIL PROTECTED] writes: : I think most of us realize that we need a solution which can be : automatically executed as part of every installworld or mergemaster : run. The debate is over the most reasonable method of doing that. My suggestion would work, and would be a viable solution, so far the only one presented in this whole silly thread. The mtree.obsolete approach is flawed, in that it's a delta without an anchor: it's all fine and good to delete things, when you know that it's a delta from/to. It's less fine, if you don't know where you are coming from. The other problem with an mtree.obsolete is that it assumes the the upgrade process completes successfully. This doesn't mean that it completes without an error in the upgrade process, it means that the resulting system functions. The only safe way to do the delete is as part of a binary upgrade process (if you can't make it reversible, then make it so the forward process can't fail). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: p05111701b9ca84c308c3@[128.113.24.47] : Garance A Drosihn [EMAIL PROTECTED] writes: : : I think most of us realize that we need a solution which can be : : automatically executed as part of every installworld or mergemaster : : run. The debate is over the most reasonable method of doing that. : : My suggestion would work, and would be a viable solution, so far the : only one presented in this whole silly thread. : : The mtree.obsolete approach is flawed, in that it's a delta : without an anchor: it's all fine and good to delete things, : when you know that it's a delta from/to. It's less fine, if : you don't know where you are coming from. Eh? If it doesn't exist, it won't be deleted. : The other problem with an mtree.obsolete is that it assumes : the the upgrade process completes successfully. This doesn't : mean that it completes without an error in the upgrade process, : it means that the resulting system functions. It would be one of three: delete automatically, move automatically, do nothing. Reasonable to me. : The only safe way to do the delete is as part of a binary : upgrade process (if you can't make it reversible, then make : it so the forward process can't fail). I disagree. That's no more or less safe than any other way. Or let me rephrase, it is no less safe than a make installworld. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
M == M Warner Losh [EMAIL PROTECTED] writes: M I think that we need a mtree.obsolete that goes through and M deletes these sorts of things as part of installworld/upgrade M scripts. No solution like this will ever work for everyone, or in every situation. For example, you generally want to nuke stale bits from /usr/include, but doing the same in /usr/lib can lead to Interesting Times. And you never know if I might be working on replacements for obsoleted bits of the OS that I'm installing into their old location. For example: adduser. Current would remove it in your scenario, even though I've re-implemented it in it's old location in my build/install tree. Yes, I could modify mtree.obsolete under /usr/src, but that seems counter-productive for a -current environment. (Thankfully, I don't own a bike, so I don't need to worry about the colour of it's shed.) One compromise is to have the 'install' target touch a timestamp file before setting off to overwrite things. Then you can use 'find mumble ! -newer ...' to search for and display possibly stale files. (A /usr/sbin/findstale script that wraps this might be a useful adjunct to mergemaster.) I use /bin/cat as a timestamp file for rough analysis purposes. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? One certainly still needs portmap(8), in its rpcbind(8) name, for NFS. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? I use: cd /usr/src make installworld DESTDIR=/some/where diff -ur /some/where / manual review. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) --On Monday, October 07, 2002 8:51 AM +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: On Sunday, 6 October 2002 at 23:42:55 -0700, David O'Brien wrote: On Mon, Oct 07, 2002 at 04:02:51PM +0930, Greg 'groggy' Lehey wrote: It's been a while since we've used portmap(8) on -CURRENT systems. Is it still needed, or can it be removed completely? At the very least, the man page should stop claiming that it's necessary to run NFS. Are you saying we've left behind an old manpage? No, I'm asking whether we have left behind both an old man page and an old binary. On closer examination, though, it looks like this is the result of installing a 4.7 system and immediately upgrading it to 5-CURRENT, so that the dates of the files looked pretty much the same. Sorry for that confusion. What's the recommended way of getting old binaries off the system? I use: cd /usr/src make installworld DESTDIR=/some/where diff -ur /some/where / manual review. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, 7 Oct 2002, Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) Well, mostly all. (1) If a file is removed from the source tree, it won't be replaced, it will just get stale. That's what happened with grog's portmap and portmap.8.gz. Even more annoying are the man cache files which also need to be flushed. (2) Symlinks and directories are not replaced. If you do ls -l in lib, you'll see that the old files are (a) obsoleted libraries or library versions, and (b) the symlinks. Depending on what applications are present in your system, you may be able to flush (a), but be cautious about (b). Note that the caution regarding (a) is because old libraries may still be used by old dynamically linked applications. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On Mon, Oct 07, 2002 at 04:32:10AM -0700, Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? It depends. If you have INSTALL='install -C in /etc/make.conf, then some (or even all) of the files in the named directories will not be replaced. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
M. Warner Losh writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. Having something that warns may be a good idea. Having something that auto-deletes less so. I sometimes keep old stuff on purpose to prevent foot-shooting when the replacement is not up to scratch. No objection if mergemaster asks permission to delete stuff, for example. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Joel M. Baldwin wrote: Shouldn't ALL of the files in /bin, /usr/bin, /usr/include, /usr/lib etc be replaced during an installworld? They are replaced... if they exist boith before and afterward. They are also created... if they did not exist before, but do exist afterward. What's not done is that they are not *removed*... if they existed before, but were not recreated. Note that every port or package installed on your system, and every file in every user directory, also does not exist as a result of the source tree. Therefore removing everything that is not a result of the source tree would be... Bad(tm). I've always looked for files older than the last installworld and moved them aside thinking that they're obsolete. ( aside, not delete, just in case ) Yes. And you will have to continue to do so. Base system component files are not removed when they are made obsolete, because they are not registered anywhere, and thus their obsolete status is not known. Consider the case of a *new* compat-4 library for 5.x, which is required for certain 4.x programs to run, or Perl, which is a port/package in 5.x, rather than a base system component. You cannot just remove bas system components because they no longer exist, when you have software which depends on them, unless you re-track the dependencies, and force the install of the now-optional components. For Perl, this is not as hard as for compat-4, or something similar, which will be dependend upon by programs which are not identified to the package managements system, even if you (empasis on _you_) were to do the work to register the rest of the OS into the package management system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Daniel Flickinger wrote: Name: text textType: Plain Text (text/plain) Encoding: 7bit As an EMACS afficionado, perhaps I can get you to fix AtillaMail? Right now, even without attachments other than the message body, it adds: Content-Type: text/plain; charset=iso-8859-1; name=text Content-Transfer-Encoding: 7bit Content-Disposition: inline The correct thing to do is to claim the character set is us-ascii and/or to use 8bit, base64, or quoted-printable transfer encoding. As it is, everyone who has any intelligence at all has to manually go through an additional step to decode your message bodies, since they have their mainl clients configured to avoid automatic invocation and retransmission of worms and other programs. Thanks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: M. Warner Losh writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. How will this work for perl, which is not removed, but is instead replaced with a stub shell script? I guess you can live with binaries linked against older versions of shared libraries suddenly not functioning... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: : It's been a while since we've used portmap(8) on -CURRENT systems. Is : it still needed, or can it be removed completely? At the very least, : the man page should stop claiming that it's necessary to run NFS. I think that we need a mtree.obsolete that goes through and deletes these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. How will this work for perl, which is not removed, but is instead replaced with a stub shell script? Anything that gets overwritten during the normal install process is already taken care of. We're just trying to get rid of files which are not installed by 'make installword' but used to be once. I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: How will this work for perl, which is not removed, but is instead replaced with a stub shell script? Anything that gets overwritten during the normal install process is already taken care of. We're just trying to get rid of files which are not installed by 'make installword' but used to be once. I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. This won't work for Perl (which is why I picked it as my example). In order to do what you are suggesting, you will need to create a delta between previously installed binaries and currently installed binaries, and remove anything not in the intersection set, but in the set of previously installed binaries. That would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the startup scripts that referenced portmapper instead of rpc.bind -- unless they were *also* overwritten. You overwrite things which are in the intersection set with new binaries. And you install new binariers that didn't exist before: anything not in the intersection set, but in the set of newly installed binaries. The intersection case is problematic, in that you would overwrite your old, real perl with a shell script stub, which also makes perl a good example for this experiment. The last case is not a problem, since it's new stuff (of course). Even starting today, if you had a packing list for the next 4.x release, so that you could differentiate what went away from what was not installed from new stuff, it doesn't help existing installations that are trying to upgrade from source. This has kind of been discussed before; really, you have to teach the binary revision management tools about the base system; for perl, in particular, this lets you install the port version when you know you are upgrading from something with a system version and something with a system stub that doesn't work (really, you want a package version, not a port version, for this -- forcing the build of the package as part of the build of the system, as painful as that sounds). The same thing applied to installing a compat4 when upgrading from 4.x to 5.x. The user is then free to manually deinstall the compat4 package, if they do not require it. Personally, I've already been screwed multiple times on libc not having a version number bump, when the X binary distribution for 4.x is attempted to be run on 5.x (the simplest example is the resize program, which fails due to undefined symbols). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED] Archie Cobbs [EMAIL PROTECTED] writes: : I.e., if a file is not installed by 'make installworld' then by : definition it's not required for a correctly functioning system. The only exceptions to this rule would be if something was once in the system, but is now a port Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. This won't work for Perl (which is why I picked it as my example). In order to do what you are suggesting, you will need to create a delta between previously installed binaries and currently installed binaries, and remove anything not in the intersection set, but in the set of previously installed binaries. That would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the You are right in that additional programs or custom modifications that depend on the obsolete stuff would break if the obsolete stuff were removed... so you'd have to confirm everything with mergemaster. Possibly this is too dangerous to be useful. But it would be nice to get rid of those really stale header files, etc. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
On 2002-10-07 15:14, Archie Cobbs [EMAIL PROTECTED] wrote:
Anything that gets overwritten during the normal install process
is already taken care of. We're just trying to get rid of files
which are not installed by 'make installword' but used to be once.
I.e., if a file is not installed by 'make installworld' then by
definition it's not required for a correctly functioning system.
This might cause problems with ports that ``overwrite'' base-system
files. I hate ports the idea of ports writing anything outside of
${LOCALBASE}, but we already have some of those IIRC.
Giorgos.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
Archie Cobbs wrote: You are right in that additional programs or custom modifications that depend on the obsolete stuff would break if the obsolete stuff were removed... so you'd have to confirm everything with mergemaster. Possibly this is too dangerous to be useful. But it would be nice to get rid of those really stale header files, etc. Yeah, that's why this discussion keeps coming up. People keep getting bit on the butt over it. 8-). You end up having to register source, target, build, and install relationships, as well as already installed relationships. It would really suck, too, when you had a third party package that got pulled into FreeBSD proper (e.g. first import of perl, or first import of expat2, where the built version conflicts with the installed version, but the installed version is not registered into the dependency tracking framework). It's an expensive problem to fix, and there's no way to fix it and make money from it (at least the way things stand), so there's no way to recover the expenses. Basically, you have to find someone willing to pay you to do the work, and willing to accept the risk of the code not making it back into the main FreeBSD tree because it steps on the toes of someone who could veto its inclusion. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still need portmap(8)?
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2002-10-07 15:14, Archie Cobbs [EMAIL PROTECTED] wrote:
: Anything that gets overwritten during the normal install process
: is already taken care of. We're just trying to get rid of files
: which are not installed by 'make installword' but used to be once.
:
: I.e., if a file is not installed by 'make installworld' then by
: definition it's not required for a correctly functioning system.
:
: This might cause problems with ports that ``overwrite'' base-system
: files. I hate ports the idea of ports writing anything outside of
: ${LOCALBASE}, but we already have some of those IIRC.
Yes. Clearly, there are some files that should always be deleted
(stale binaries and header files), some files that should often be
deleted (those things replaced by ports under the same path, for
example), and some things we'd want to the user to removed (eg,
libfoo.so.N-1)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
