headers
Adam C. Migus | 1 Sep 2003 08:25

Re: Things to remove from /rescue


Alexey Neyman said:
> Hi, there!
>
> On Tuesday 22 July 2003 19:30, Sheldon Hearn wrote:
>> I don't see this as an unreasonable requirement, and I can't see
>> what
>> great cost it incurs that would motivate us to remove support
foraccommodate
>> it.
>environments
> Can't all this be done in a "user needs it, user adds it" fashion?
> E.g., to
> add /etc/rescue.mk that will be .include'd in
> src/rescue/rescue/Makefile,compromise
> adding the required binaries to the CRUNCH_PROGS_bin,
> CRUNCH_PROG_sbin,
> CRUNCH_LIBS lists?
>
> E.g:
> --- /etc/rescue.mk ---
> CRUNCH_PROGS_sbin += chown
>
> This will allow the "base" list to be trimmed to some minimalist
> level, and
> will still allow the users to add whatever they [think they] need to
> restore
> their system.
>
> Regards,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Jeremy | 1 Sep 2003 11:10
Picon

Re: Things to remove from /rescue

On Mon, Sep 01, 2003 at 02:25:32AM -0400, Adam C. Migus wrote:
>The whole change to dynamic linking for / is a move to "modernize"
>FreeBSD.  Thus /rescue is a "modern" attempt at creating a /stand. 
>If we're going to be "modern" we ought to think about what "modern"
>sysadmins need to "rescue" their systems.

What do you mean by a "modern" sysadmin?  Do you mean people who
believe everything should be done via a GUI and would be lost if
presented with a shell prompt?

>/rescue to me implies "what's needed to rescue you're hosed FreeBSD
>system."

Actually /rescue is only needed when you've managed to hose your
/lib, /bin or /sbin directories.  If you haven't damaged your root
filesystem, you can use all the utilities in /bin and /sbin.  If
your root is totally hosed, you need to boot from alternate media
(eg a fixit CD-ROM).

Excluding hamfisted sysadmins pointing "rm" at the wrong directory,
/rescue is probably going to be of most use to developers who have
managed to a "make world" at an inopportune time and installed a
non-functional ld.so or similar.

>Finally, this argument essentially comes down to space savings vs.
>ability to rescue the system.  Is 100K of disk space worth 2 hours
>of time due to a missing tool?

Any missing tool is probably available on the fixit CD-ROM.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam C. Migus | 1 Sep 2003 17:36

Re: Things to remove from /rescue


Peter Jeremy said:
> On Mon, Sep 01, 2003 at 02:25:32AM -0400, Adam C. Migus wrote:
>>The whole change to dynamic linking for / is a move to
"modernize"acquire
>>FreeBSD.  Thus /rescue is a "modern" attempt at creating a /stand.
>>If we're going to be "modern" we ought to think about what "modern"
>>sysadmins need to "rescue" their systems.
>
> What do you mean by a "modern" sysadmin?  Do you mean people who
> believe everything should be done via a GUI and would be lost if
> presented with a shell prompt?
>
negligibleconvenient
My apologies if this comment offends you based on what it doesn't
say.  A "modern" sysadmin could, I suppose fit, your description or
could simply be a very intelligent young person six months out of
college who has yet to aquire the skills of a more experienced
sysadmin.  I suppose it could also be an office administrator forced
to become a system administrator due to downsizing at his or her
company.

>>/rescue to me implies "what's needed to rescue you're hosed FreeBSD
>>system."
>
> Actually /rescue is only needed when you've managed to hose your
> /lib, /bin or /sbin directories.  If you haven't damaged your root
> filesystem, you can use all the utilities in /bin and /sbin.  If
> your root is totally hosed, you need to boot from alternate media
> (eg a fixit CD-ROM).
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Taylor | 3 Sep 2003 16:39
Picon

(proposal) new flag for pkg_delete

(I hope this is the right list)

Currently, pkg_delete's manpage states:

     -f      Force removal of the package, even if a dependency is
             recorded or the deinstall or require script fails.

It fails to mention that if -f is specified it will also delete any files
where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
portupgrade wiping my configuration information because it specifies -f
(as it must, in order to remove packages which are still 'in use' by other
packages).

So, I have a proposal:

Create two seperate flags (open to ideas for what to call them, say '-F'
and '-m'), which work as follows:

	-F	works as '-f' is currently documented.
	-m	ignores MD5 checksums

Then change -f:

	-f	backwards compatability (activates -F and -m)

Then portupgrade could be changed to use '-F' instead of '-f' (or whatever
it is eventually called), and should stop deleting config files.

Any comments?
(Continue reading)

Permalink | Reply | 17 comments |
headers
Bruce M Simpson | 3 Sep 2003 16:41

Re: (proposal) new flag for pkg_delete

On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> (I hope this is the right list)

Certainly is, although letting ports people know of an intended change
wouldn't hurt.

> Then portupgrade could be changed to use '-F' instead of '-f' (or whatever
> it is eventually called), and should stop deleting config files.

I'm definitely in favour. Wiping config files is Bad. I have been bitten
by this before.

BMS
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Will Andrews | 3 Sep 2003 16:47

Re: (proposal) new flag for pkg_delete

On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> It fails to mention that if -f is specified it will also delete any files
> where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
> portupgrade wiping my configuration information because it specifies -f
> (as it must, in order to remove packages which are still 'in use' by other
> packages).

Wrong way to fix the problem.  Make the ports install sample
config files and only add those to the plist, not the actual ones.

Regards,
--

-- 
wca
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 14 comments |
headers
David Taylor | 3 Sep 2003 16:55
Picon

Re: (proposal) new flag for pkg_delete

On Wed, 03 Sep 2003, Will Andrews wrote:

> On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> > It fails to mention that if -f is specified it will also delete any files
> > where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
> > portupgrade wiping my configuration information because it specifies -f
> > (as it must, in order to remove packages which are still 'in use' by other
> > packages).
> 
> Wrong way to fix the problem.  Make the ports install sample
> config files and only add those to the plist, not the actual ones.

I agree that ports should be fixed to install config files in the correct
way.

However, pkg_delete is still broken -- either the manpage should be fixed
to make it explicitly clear that using -f will result in MD5 checksums
being ignored, or the user should be given the option.

Since portupgrade _needs_ to ignore dependencies, it currently has to use
the -f flag.  It has no reason to delete files that the user has modified,
unless it is asked to.

It may not be the correct solution to the problem I mentioned, but it is a
quick workaround that will prevent my config files being wiped when I run
portupgrade, at least until all the ports are fixed -- which could take a
while -- I submitted a patch to the (now ex, I think) maintainer of innd,
but it was never committed, and became out of date.

It is also a solution to a real problem -- there is no way to override
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Pentchev | 3 Sep 2003 17:06
Gravatar

Re: (proposal) new flag for pkg_delete

On Wed, Sep 03, 2003 at 07:47:34AM -0700, Will Andrews wrote:
> On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> > It fails to mention that if -f is specified it will also delete any files
> > where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
> > portupgrade wiping my configuration information because it specifies -f
> > (as it must, in order to remove packages which are still 'in use' by other
> > packages).
> 
> Wrong way to fix the problem.  Make the ports install sample
> config files and only add those to the plist, not the actual ones.

Exactly.  Look at www/apache13/pkg-plist for an example (of course,
there are lots of others, this is just the example I come across
most often).

G'luck,
Peter

--

-- 
Peter Pentchev	roam <at> ringlet.net    roam <at> sbnd.net    roam <at> FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am not the subject of this sentence.
Permalink | Reply | 0 comments |
headers
David Taylor | 3 Sep 2003 20:29
Picon

Re: (proposal) new flag for pkg_delete

On Wed, 03 Sep 2003, Will Andrews wrote:

> On Wed, Sep 03, 2003 at 03:39:48PM +0100, David Taylor wrote:
> > It fails to mention that if -f is specified it will also delete any files
> > where the MD5 checksum is incorrect.  I have now been repeatedly bitten by
> > portupgrade wiping my configuration information because it specifies -f
> > (as it must, in order to remove packages which are still 'in use' by other
> > packages).
> 
> Wrong way to fix the problem.  Make the ports install sample
> config files and only add those to the plist, not the actual ones.
> 

As I stated in my previous reply, I am aware this is a real problem (which
I would also like to fix, in a more 'proper' way than the pkg_delete
patch), so I have another suggestion.

However, I beleive this suggestion has been made repeatedly before, but
noone has ever come to an agreement, mainly because noone has ever done
much to make it happen.

The suggestion is, to use a mergemaster style tool to handle port/pkg
config files.  Whilst we're at it, the base system mergmaster could
(optionally?) use the new system to.

The main features I could see as desirable would be:

	Package/port installed config files will not overwrite any files.

	Deinstalling packages/ports will not by default remove config data.
(Continue reading)

Permalink | Reply | 10 comments |
headers
The Anarcat | 3 Sep 2003 21:14
Gravatar

config files in packages (Re: (proposal) new flag for pkg_delete)

(This is just moot since I have absolutely no time to implement this,
but it's food for thought i have been digesting for a long time now)

Debian adopted what I think is an elegant solution to this
problem. The configuration files are marked as such in the
package. When deinstalling, you must explicitely ask it if you want
the configuration files to be removed.

When upgrading or installing over, the package "knows" the old MD5 of
the config files, so if they match (ie the config wasn't modified),
they're overwritten. If the md5 don't match (ie the config was
modified), the user is presented with an interface similar to that of
mergemaster (minus the merge capabilities, unfortunatly).

I think this scheme could be generalized to all the files in the
package. What I would see for our pkg_tools is the following:

1- overwriting of unmodified files
2- merging of modified files

(1) already works, provided that we don't use the -f flag to
pkg_delete, since the old files simply get deleted.

(2) would need a better integration between pkg_add and pkg_delete,
because problem is right now, unless I'm mistaken, a package upgrade
is made in 2 seperate process that don't really talk to each other:
pkg_delete and pkg_add.

The way I see it, ideally, pkg_add should be able to call pkg_delete
on the old package. When files would be left behind, it would mean
(Continue reading)

Permalink | Reply | 9 comments |

Gmane