Subject: Yet Another Hacktivity - An RPM Spec file for building Fortune Collections

From: Shlomi Fish <[email-masked]>
Date: Sat, 1 Jun 2002 03:02:54 +0300 (IDT)

Included below is an RPM Spec for building a collection of fortune files.
It is specific to my collection, but hopefully can be customized to other
sources with relative ease.

I plan to use it as the basis for my fortune2rpm hack, which I have some
great plans for.

	Shlomi Fish

#######################################
# Base Macros which need to be set
%define packageprefix fortune-mod-fortunes
%define packagebase shlomif
%define archivebase fortunes-shlomif
%define version 0.2.2
%define fortunefilesprefix shlomif-

# Derived Macros
%define name %{packageprefix}-%{packagebase}
%define archivewithver %{archivebase}-%{version}
%define archivefull %{archivewithver}.tar.gz
Name: %{name}
Version: %{version}
Release: 6
Copyright: Free to use but restricted
Group: Toys

Source: http://vipe.technion.ac.il/~shlomif/humour/fortunes/%{archivefull}
BuildArch: noarch
Buildroot: %{_tmppath}/%{name}-root
URL: http://vipe.technion.ac.il/~shlomif/humour/fortunes/
Serial: 1
Requires: fortune-mod
Summary: Shlomi Fish' Collection of Fortune Cookies

%description
This package contains several collections of fortune cookies by Shlomi Fish.
Namely, a collection of his own quotes, some of his favourites from various sources; a collection of excerpts from the T.V. Show Friends; the Rules of Open
Source Programming, and a collection of reasons why there is no iglu cabal.

%prep
%setup -n %{archivewithver}

%build

myprefix="%{fortunefilesprefix}"
rm -f *.dat
ls | grep -v "\\." | grep -v "[A-Z]" | \
    ( while read T ; do        \
        mv "$T" "${myprefix}$T"  ;     \
        /usr/sbin/strfile "${myprefix}$T" "${myprefix}$T.dat"  ;    \
     done )

%install

rm -rf $RPM_BUILD_ROOT
mkdir $RPM_BUILD_ROOT
for dir in usr usr/share usr/share/games usr/share/games/fortunes ; do
    mkdir $RPM_BUILD_ROOT/$dir
done
# This will only work in bash and friends.
for I in *.dat ; do
    cp $I ${I%%.dat} $RPM_BUILD_ROOT/usr/share/games/fortunes
done

%post

%postun

%files
%defattr(-,root,root)
/usr/share/games/fortunes/*

%clean
rm -rf $RPM_BUILD_ROOT

%changelog
* Fri May 31 2002 Shlomi Fish <[email-masked]> 0.2.2-2
- Added macros all over the place

* Thu May 30 2002 Shlomi Fish <[email-masked]> 0.2.2-1
- first release - testing.

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: OmerM <[email-masked]>
Date: Sat, 1 Jun 2002 13:57:31 +0300

> I plan to use it as the basis for my fortune2rpm hack, which I have some

Speaking of suboptimal design decisions that are to happen when
some other guys do not put their best in finding optimal algorithms:

Do you always define 3 level of indirection to put a literal string
that will be used once?

---

From: Tzafrir Cohen <[email-masked]>
Date: Sat, 1 Jun 2002 15:52:41 +0300 (IDT)

> Do you always define 3 level of indirection to put a literal string

You obviously didn't write many makefiles ;-)

Considering that this is going to be processed by RPM to produce a number
of shell scripts that spits a lot of output, that redirection is
negligble.

There are also quite a few levels of redirection in /usr/lib/rpm/macros

However, it helps to make the code more maintainable. You can never know
when the name is going to be used again.

-- 
Tzafrir Cohen
mailto:[email-masked]
http://www.technion.ac.il/~tzafrir

---

From: OmerM <[email-masked]>
Date: Sat, 1 Jun 2002 17:41:02 +0300

On Saturday 01 June 2002 15:52, Tzafrir Cohen wrote:
> > > Included below is an RPM Spec for building a collection of fortune
> > > files. It is specific to my collection, but hopefully can be customized
> > > to other sources with relative ease.
> > >
> > > I plan to use it as the basis for my fortune2rpm hack, which I have
> > > some great plans for.
> > >
> > > 	Shlomi Fish
> > >

Actually, I did not:) I'm using Teamware and mkmf at work and have to worry
about design and performance of my programs, not my makefiles.

However, I did write enough code to have my too-complicated-without-a-reason
bit set while seing three levels of naming when one direct name would suffice. 

> of shell scripts that spits a lot of output, that redirection is

I do not buy this statement. In similar manner, considering that email message
is going to be broken to bits, transformed from one endiness to the other and
after all displayed as an array of pixels, logic errors in a message are 
neglible.

Considering that a program file will be broken to sequence of zeros and ones, 
design considerations are not relevant.

I disagree with abovementioned attitude.

> when the name is going to be used again.

I disagree with that point too. Either you do know what you do with a name or
you do not know. If you do not know what you do with a name, then you do not
know well the code that you had written.

---

From: Shlomi Fish <[email-masked]>
Date: Sat, 1 Jun 2002 17:53:32 +0300 (IDT)

> about design and performance of my programs, not my makefiles.

Well, we common people do have to write such beasts and we know what we're
doing. Part of the reasons why I used so many macros, was that I intended
it to be generated and maintained by a script and so had to make sure it
is as modular as possible.

> bit set while seing three levels of naming when one direct name would suffice.

Did you take a look at the makefiles generated by GNU Autoconf? And mind
you they follow the GNU standard for makefiles.

> after all displayed as an array of pixels, logic errors in a message are

What do you mean by logic errors? The problem in that case is that the
E-mail message when sent and when received will always be identical. OTOH,
a makefile, whether abstracted or unmodular can generate the same result
and at roughly the same time. (O(n)). It's an input file that has to be
processed to produce the final product, and so speed is not the issue.

> design considerations are not relevant.

Nothing will happen if a makefile would take 5 times to be processed than
the most generic makefile. Unless you have a very slow hardware, you won't
even feel the difference.

Regards,

	Shlomi Fish

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

---

From: Tzafrir Cohen <[email-masked]>
Date: Sat, 1 Jun 2002 18:26:17 +0300 (IDT)

On Sat, 1 Jun 2002, OmerM wrote:

> about design and performance of my programs,not my makefiles.
>
> I disagree with that point too. Either you do know what youdo with a name or

Let's examine it, then.

The Name header is composed in three stages.

1. %define packageprefix fortune-mod-fortunes
   %define packagebase shlomif

2. %define name %{packageprefix}-%{packagebase}

3. Name: %{name}

Actually, I believe that with a better look at the specifications of RPM
it would turn out that (2) is unnecessary, because the Name header can be
used directly. However, assuming it is not, you may need to reuse the name
of that header somewhere later.

Therefore if you want to use the name of the package later (for instance:
as part of the README, part of the description, or be used in one of the
scripts: all of those are very useful in a template spec, which Shlomi
seems to have in mind, and can be useful in some other places) you need to
give a seperate definition for it.

Therefore it has become a standard part of spec files (at least of those
authored by mandrake, which is probably the example Shlomi used).

So it has an obvious atvantage of code maintainability, and negligble
performance price, since rpm already does much more, and wastes much more
time, anyway.

Does this answer your question?