Fedora's Amanda mispackaged? (was: Re: Backing up whole system)

[Michael Schwendt]

On Mon, 11 May 2009 14:06:13 -0400, Gene wrote:

> Boring and repetitive operations such as that get consigned to 
> scripts with a chmod +x applied.

You see? That's a first step towards RPM-packaging the software. Several
sections of an RPM .spec file are a shell script (aided with RPM-specific
variables/macros which are expanded prior to executing the script).

One of the key differences is that you configure a software tarball
to install into a buildroot directory instead of directly into your
system (which you couldn't do anyway when not using root for that).

> >You may need to eradicate all your custom configuration prior to starting
> >from scratch with Fedora's packages. Else it may not be feasible for
> >other people to reproduce issues you run into.
> 
> Taint gonna happen.  It runs the way I have it setup, or not at all. I have no 
> intentions of destroying 30 days of legacy backups I might need tomorrow just 
> to placate your ego.

Has nothing to do with my ego.

I'm not involved in the making of Fedora's amanda pkgs, but have a general
interest in learning about broken Fedora packages, which are broken
because of mispackaging. Depending on what issues you point out I might
take a look myself. As with other huge package collections, there are
poorly maintained packages as well as semi-orphans, which are ignored by
the community of users (and sometimes based on rumours that spread via
message boards), who roll their own builds instead. In the worst case, a
packager is not even aware of packaging bugs and run-time
problems. Sometimes packagers don't use the software anymore, but don't
call for a new maintainer.

> >The .rpm{new,save,orig} mechanism only works with files tracked in the
> >local RPM database.
> 
> Ahh, but that is how it should work.  I see no reason I should have to do a 
> chattr +i on stuff that needs protection from rpm.  But in fact I have  
> several so marked, including that file as of now.

When you install an RPM package for the first time, it needs to start in a
pristine state - by extracting the files stored inside the packge.
You're bound to fail if you want RPM to not overwrite existing files.
Where to start? Where to stop? Overwrite shared libraries? Don't overwrites
binaries and config files?

On an RPM installation, put your own stuff under /usr/local, an area
that is not touched by RPM packages created by your Linux distributor.
 
> >> So where does the rpm install it?  Should it not find stuff in /bin before
> >> it looks in /usr/bin?  And in /usr/lib before it looks in /usr/local/lib
> >> (or libexec).??
> >
> >rpm --query --list amanda
> 
> not installed.

Bad taste of humour.

> >Please present step-by-step instructions on how to reproduce problems
> >with Fedora's Amanda packages.
> 
> Here, or on the amanda-users list where such a conversation would be much more  
> germane?  We had an rpm 'expert', from the fedora camp, show up on that list 3 
> or so years ago, said he was the packager and promised to 'fix' the perceived 
> packaging problems of amanda.  We explained what we thought were the problems 
> at the time & he disappeared again without giving any of us a chance to try 
> his 'fixed' packages, not willing to stick around and actually _use_ the code 
> or take feedback.  That was, shall we say, much less than useful for all 
> concerned.

If you say Fedora's Amanda packages are broken, it would be justified
to post it here and [even better] track the issues with a bug in
Fedora's bugzilla. A very convenient link is this:
http://bugz.fedoraproject.org/amanda

It lists the tickets and also features a direct link to where users
can open a new ticket with a _single_ form in bugzilla.

> Blind insistence that rpm is the best solution is equ to saying that one 
> religion is the only true religion.

Not my interest. The relevant part of this thread has not been about
whether RPM is best, but about you complaining about Fedora's amanda
packages being broken or something similar. The interesting thing would
be to learn how exactly the packages are broken.