Re: Patch for 1.5.0: new feature provide and some small fixes

[Uwe Koloska <koloska@xxxxxxxxxxxxxxxxxxxx>]

Felipe Sanchez wrote:

>
> On Fri, 7 Dec 2001, Uwe Koloska wrote:
>
>
>>Here are the changes:
>>- new feature: provided features
>>    maybe this has to be toggled only for preparation of
>>    rpm-packages
>>
>
> Sounds nice. Can you send a cut & paste of a checkinstall
> session running
> with this change and using the "provides" feature?


I don't know exactly what you mean, but here comes the log of my
install of "ctags-1.5.1":


--- snip ---
flute  ctags-5.1 # checkinstall -R

checkinstall 1.5.0, Copyright 2001 Felipe Eduardo Sanchez Diaz Duran
           This software is released under the GNU GPL.


The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs?  [y]:

Preparing package documentation...OK

Installing with "make install"...

========================= Installation results 
===========================

Copying documentation directory...
cp ctags /usr/local/bin/ctags  &&  chmod 755 /usr/local/bin/ctags
strip /usr/local/bin/ctags
cp ./ctags.1 /usr/local/man/man1/ctags.1  &&  chmod 644 
/usr/local/man/man1/ctags.1
if [ -x /usr/local/bin/ctags ]; then \
    cd /usr/local/bin && ln -s ctags etags; \
fi
if [ -f /usr/local/man/man1/ctags.1 ]; then \
    cd /usr/local/man/man1 && ln -s ctags.1 etags.1; \
fi

======================== Installation succesful 
==========================

Copying files to the temporary directory...OK

Building file list...OK

Stripping ELF binaries...OK

Please write a description for the package. Remember that 
pkgtool shows
only the first one when listing packages so make that one 
descriptive.
End your description with an empty line or EOF.
>> Generate tag files for use with vi and other editors
>> ctags (from Darren Hiebert) generates tag files from source 
code in C,
C++, Eiffel, Fortran and Java to be used with vi, its 
derivatives, emacs
and several other editors.
>> >> >>


This package will be built according to these values:

1 - Summary: [ Generate tag files for use with vi and other 
editors ]
2 - Name:    [ ctags ]
3 - Version: [ 5.1 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group:   [ Applications/System ]
7 - Architecture: [ i386 ]
8 - Source location: [ ctags-5.1 ]
9 - Alternate source location: [  ]
A - provided Features: [ ctags ]

Enter a number to change any of them or press ENTER to continue: 6
Enter the new software group:
>> Development/Tools

This package will be built according to these values:

1 - Summary: [ Generate tag files for use with vi and other 
editors ]
2 - Name:    [ ctags ]
3 - Version: [ 5.1 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group:   [ Development/Tools ]
7 - Architecture: [ i386 ]
8 - Source location: [ ctags-5.1 ]
9 - Alternate source location: [  ]
A - provided Features: [ ctags ]

Enter a number to change any of them or press ENTER to continue:

**************************************
**** RPM package creation selected ***
**************************************

Building RPM package...OK

Installing RPM package...OK

Erasing temporary files...OK

Deleting doc-pak directory...OK

Deleting temp dir...OK


**********************************************************************

 Done. The new package has been installed and saved to
 /usr/src/packages/RPMS/i386/ctags-5.1-1.i386.rpm

 You can remove it from your system anytime using:

      rpm -e ctags-5.1-1

**********************************************************************

--- snip ---


> You should note that it has always been possible to specify
> the "provides" section of the spec file by actually *writing*
> a spec file and telling checkinstall to use it with the
> "--spec" command line option.

Yes, of course.  But I am a lazy person and don't want to type 
more than absolutely needed.  All things that can be automated 
should be automated ;-)))

Do you know why rpm3 (I don't know 4) doesn't make an implicit 
"provides" for the package name?  The manpage says it would ...

> You can even get a template of the spec file if you tell
> checkinstall not
> to delete the auto-generated one with "--delspec=no". Once you
> have it you
> can edit it to fill your needs, like for example adding the
> "Provides:"
> section. And you can reuse it for other packages as well,
> using the
> "--spec" option.

What about a special directory like RPMROOT/checkinstall with 
the automatically created specfiles and doc-packs?  Then 
checkinstall could use this files if they are present.  (only a 
quick thought, nothing that I have really thought about in depth)

> It would be nice to be able to specify the provides section
> with another
> command line option or via a "provides-pak" file or something,
> though.
>
> I'll think about the best way to implement it  ;-)

Yeah, my patch is only a quick solution to the problem.  It's 
really bad, that if I decide to change the provides section, I 
have to retype the package name ...

>>- don't delete doc-pak and description-pak if they are present
>>  when running checkinstall without this, both are deleted
>>  after a default installation of checkinstall itself
>
> That's what the checkinstallrc file is for. Go edit it
> instead:
> /usr/local/lib/checkinstall/chechkinstallrc
>
> Or you can use "--deldesc=no --deldoc=no".

No, both options (checkinstallrc and commandline options) are 
there for cusomization.  What I want with this new behaviour is 
to make the default of checkinstall non destructive.

Think about the standard install for checkinstall itself:

  make
  <su>
  make install
  checkinstall

after this two files from the distribution have disappeared. 
And if you issue (for whatever reason) 'checkinstall' a second 
time, it acts different from the first invocation.  It asks 
about a doc-pak and only has the default settings for the spec-file.

I think a program should only delete files if it has produced 
them or if the user says so.

Sure, my patch has only half of the way:
- it makes sure the program doesn't delete something it hasn't
  created
- there is no option for the user to command this

I hope this makes my intentions clear
Yours
Uwe Koloska

--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany