On Wed, 16 Aug 2000, Levente Farkas wrote:
>> >I think it would be a good idea that binary packages (built with rpm) to
>> >automagically include the spec file (and to place it under
>> >/usr/doc/package.../). This is helpfull in 2 situations:
>> > - as an inspiration for new package builders
>>
>> I disagree. It is just extra file clutter on the hard disk that
>> is totally unnecessary. If someone wants inspiration for
>> building packages, the .spec is in the src.rpm. The spec is
>> useless without the rest of the files that it uses to build
>> with. In other words, someone can't easily build an RPM by
>> looking merely at the spec, they need to understand the
>> process. If they are trying to understand the process, they can
>> take the time to download a few .src.rpm packages and learn. In
>> less than an hour of fiddling, one can create some simple
>> packages. I don't see how having the .spec available for
>> installed packages helps anyone with anything. One could argue
>> then also that having the source code installed along with
>> binaries is also useful since it helps one to learn how to write
>> code... Bad argument.
>
>although may be not necessary, but would be useful. how many rpm did
>you made ?
How many RPM's have I made personally? Gee, that would be hard
to enumerate. I've packaged a lot of stuff since Red Hat 5.0
when I learned.
>and how many doc file did you read ?
Initially? One. the RPM Howto. Oh, and the man page. I then
took the .src.rpm for a few small packages from either Red Hat
5.0 or from Red Hat contrib, and installed them to analyze the
way they built.
Anyone not willing to get an SRPM to play with is hardly going to
learn how to create RPM packages.
After that, I began creating smaller simpler packages, things
that more or less compiled from the tarball by doing
"make" without fuss. Then I did "wine", the windows emulator,
PINE (modified by me), and then on to bigger and better. I then
downloaded the Maximum RPM book, read it for an hour, skimming
around and made a bunch of new RPM's. Expecting someone to read
the docs out there is not a big expectation.
If someone wants to learn how to package RPM's they should do so
properly. Read the manpage for RPM to be familiar with
invocation, etc.. Read the HOWTO to learn how to build a simple
package. Take a package apart and build it and learn how it
works, then roll your own.
The installation of binary application packages is for the
purpose of running software, documenting how to use that
software, and it's configuration files. It has nothing to do
with teaching how to learn how to build RPM packages. That is my
point. .spec files are NOT documentation for a package, not
config files, not binaries and not anything the application needs
to do its job, therefore they have nothing to do with being
included in .{%arch}.rpm packages.
Even if the .spec files _were_ installed with every package, the
1 in 100000 users that look at 1-5 out of the 2000 .spec files
that would be installed, would then have to get some src.rpm code
likely to get going anyway. After they've learned what they
could from the spec file (about 15 seconds worth) they would have
little use for them anymore. .spec files are not documentation
on how to build packages. The HOWTO is a start, and the book
Maximum RPM is a finish. The book is free download from rpm.org.
>Ini you can said doc files are useless since most people don't
>read it (and there is an rpm option not to install them). for
>me and may be many people who has same deeper knowledge the
>spec file is very informative, you can find out the configure
>and make options for the package many install options which
>usally not so trivial from the summary and description files.
.spec files are useless to users. They are only useful for
developers. Developers will be either writing source and
packaging it, or downloading source and putting it in RPM
format. In either case, it takes very little time and effort to
snag a couple .src.rpm's to work with until you've learned the
ropes. It is not worth cluttering up peoples hard disks with
extra files that are not going to be used by 99.99% of the
installed user base. While you might _think_ the files are
useful to you for developing, they are minimally useful to the
majority of people installing Red Hat, and they are certainly not
something that belong in the binary RPM's because of that fact.
At any point, this is really pointless because Red Hat isn't
going to start doing it anyways.
>and one file for each package is a real waste of space ???
1 file == 1 inode. 2000 packages = 2000 files = 2000 inodes =
2000 * 1-2-4kb. At 4kb, 4k*2000 isn't a lot of disk space, but
it is no reason to go wasting it. As I said, the argument that
it makes it easier for the 1 in 100000 people trying to learn RPM
packaging is not going to cut it. We've got 1 maybe 2 or even 3
people thinking this, and it is just not going to happen. It was
an idea, and that is fine, but my point in the thread is to
illustrate how to learn RPM. If you want to learn it, get some
RPM's. If you're not willing, then you're not serious. Filling
the distribution up with cruft files for one silly purpose leads
to filling it up with more silly files for the next purpose.
The reason it wont happen is the same reason that Linus rejects
cruft ideas from the Linux kernel source. Some things belong in
the kernel source, and some things do not. "tar" would be much
faster if put in the kernel source, as would "netscape", but they
don't belong there, and wont ever go in there. Likewise .spec
files don't belong in binary rpms installed, and they wont ever
go there either.
>I don't think so. there are many place were are the waste is
>much bigger.
It isn't really a matter of how much space as it is a matter that
it would be needlessly wasted space on thousands of computer
systems out there to which the majority of users have absolutely
no need for the files at all. The few that might have a use for
them, have very little chance of needing the .spec files for
every single installed package on the system, and of the few
.spec files that might be useful, they can get them from the
source RPM easily. Anyone truely having a need for ALL of the
.spec files is most likely revamping the entire distribution
themselves, and this is not a light project. Recompiling the
entire thing requires the source code, which is in the src.rpm
along with the .spec file that builds it. Should the source code
also be included in the binary RPM just in case someone wanting
to learn how to make "Makefiles" or autoconf "configure" stuff
needs them? See, putting Makefiles for every package doesn't
make much sense either does it?
>or you can use raiserfs if you worry about the small files. and
Reiserfs is not officially in the Linux kernel, nor in Red Hat's
kernel if I understand correctly. Telling someone to switch
filesystems to avoid the space consumption from junk files does
not solve the problem. The junk is still there.
>you always have to download the srpm is a much bigger waste of
>time, space and money. So I don't think it's a real must, but
>as you said it's a totaly bad idea I have to say you are wrong.
I think I see the problem more properly now. You want the .spec
file from a particular .src.rpm package, and you don't want to
have to download that entire package. That makes sense. Putting
it in the binary RPMS for your installed programs is NOT the
correct solution. Getting someone to write a script to take out
all of the .spec files for Red Hat and put THEM into a directory
for download is a FANTASTIC idea. That way you only download the
.spec file, which is what you want.
Or better yet, take all the .spec's and put them in one big
tarball to download, or heck - even an RPM.
rpm -ivh specs-6.2.i386.rpm
THAT is the way to do it. You get the specs if you want them,
nobody else has junk on their disks.
Now you just need someone out there that has all the srpm's to
make you an RPM containing them all... Hmm.. I have them
all.. ;o) I know how to extract them.... and how to package
them... ;o) Probably only take a half hour to whip up a script
to parse all .spec's out and make a .spec to build the specs rpm
with. Question: Should the specs .spec get included in the
specs spec directory for the specs rpm of specs?
;o)
The only problem is, if Red Hat were to package this and include
it with the distribution, it would have to be updated EVERY TIME
a new package was updated...
Really though... trust me... get Maximum RPM.
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
