[desktop-discuss] snort, libpcap added to SFE (was: spec files question...)

[Eric Boutilier]

FYI, Per the info in Matt/Laca's post below, I added a couple
packages to the repository last week:

     SFEsnort.spec - intrusion monitoring
     SFElibpcap.spec - packet capture library (used by Snort)

These specs currently just invoke ./configure with default
parameters (except --prefix). Also, I've only briefly tested
the binaries and only on x86. So any help with testing, or
suggestions for configure would be great.

Eric


On Thu, 17 Aug 2006, Matt Keenan wrote:
> Actually the spec-files-extra repository is now on sourceforge.net.
>
> ----------------snip-------------------
>
> all spec-files-extra were moved to sourceforge.net.
>
> Use https://svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/trunk/
> as the svn root to check out.
>
> If you would like write access to the new repository (and I encourage
> everyone), please get a sourceforge.net account and send me your user
> ID.
>
> Note that the package names are now prefixed with SFE and all packages
> install to /usr.  In case of conficts with Solaris components in /usr,
> /usr/gnu should be used.
>
> Bugs can be reported at
> http://sourceforge.net/tracker/?func=add&group_id=125443&atid=865175
>
> You can also browse the spec files here:
> http://svn.sourceforge.net/viewvc/pkgbuild/spec-files-extra/trunk
>
>
> Laca
>
> --------------snip---------------
>
>
>
>
> Laszlo (Laca) Peter wrote:
>> On Fri, 2006-07-14 at 10:41 -0500, Eric Boutilier wrote:
>>
>>> Question about the %files section of spec files. I find
>>> specifying directories with and w/out %dir, and/or with and
>>> w/out wildcards confusing, as described below. Could someone
>>> clarify and maybe comment on best practices in this regard?
>>> (The RPM spec file tuturorial I'm using isn't very helpful in
>>> this regard.)
>>>
>>
>> It's described in max-rpm here:
>> http://rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE
>>
>>
>>> Eric
>>>
>>> 1. Does the following line mean to include only the
>>>     directory %{_datadir}/aclocal and nothing else
>>>     (i.e. its contents will be specified elsewhere)?
>>>
>>>     %dir %{_datadir}/aclocal
>>>
>>
>> Yes.  Basically, the default is to process directories recursively and
>> %dir makes it non-recursive.
>>
>> Also, any parent directories are also added, using the last %defattr in
>> the %files section, unless you expicitely list them elsewhere in %files.
>> I.e. if you have
>>
>> %files
>> %defattr (-, root, bin)
>> %{_libdir}/myapp/foo/bar
>> %defattr (-, root, sys)
>> %{_datadir}/myapp
>>
>> Then %{_libdir}, %{_libdir}/myapp and %{_libdir}/myapp/foo
>> will be added with root:sys owners.
>>
>> However, if you have this:
>>
>> %files
>> %defattr (-, root, bin)
>> %{_libdir}/myapp/foo/bar
>> %defattr (-, root, sys)
>> %{_datadir}/myapp
>> %attr (0755, root, bin) %{_libdir}
>>
>> then %_libdir will be root:bin, %{_libdir}/myapp and
>> %{_libdir}/myapp/foo will still be root:sys.
>>
>> This is kinda obscure, so it's better to use just one %defattr and
>> specify the attributes of well know directories like %{_libdir}
>> and %{_datadir} explicitely.
>>
>>
>>>     (I copied this from nvu.spec)
>>>
>>> 2. Do the following lines all mean to include the
>>>     directory %{_datadir}/aclocal and all its contents?
>>>
>>>     %{_datadir}/aclocal
>>>     %{_datadir}/aclocal/
>>>     %{_datadir}/aclocal/*
>>>
>>
>> Yes, almost.
>>
>> The first 2 are exactly the same.
>> The third one is a tiny bit different, because of what I described
>> above.  I.e. %{_datadir}/aclocal itself will have the permissions
>> specified in the last %defattr.
>>
>> Note: Due to an open bug in pkgbuild, the %files entries are not
>> normalised so you may get an error for extra /'s.
>>
>> Laca
>>
>>
>>>     (I copied these from cherokee.spec, SDL.spec,
>>>     and glibmm.spec respectively)
>>>
>>> _______________________________________________
>>> desktop-discuss mailing list
>>> desktop-discuss at opensolaris.org
>>>
>>
>> _______________________________________________
>> desktop-discuss mailing list
>> desktop-discuss at opensolaris.org
>>
>