Menu
▾
▴
hpoj-devel
|
From: <pa...@rc...> - 2000-12-29 23:07:34
|
Hi, Jarl.
Jarl Friis wrote:
> I have downloaded the stable version 0.7, but I consider it relevant to
> put the ptal-printd in the sbindir instead of the bindir. I have changed
> the Makefile.in, and configure.in, configure accordingly, and made a
> diff-file (attacehd)
Yes, it might be more appropriate to put daemons such as ptal-printd in
${prefix}/sbin, particularly as I add more daemons. I'll take a look at
your attachments later because I can't seem to decode them with the mail
client I'm using at the moment (not your fault).
> I am also working on a SuSE-7.0-pro RPM. I am also quite new to RPM
> building. It install quite allright, but I am very unsure about the
> dependancies, so don't trust them (yet).
Timothy Lee has been working on a RedHat SRPM, so you might want to
coordinate your efforts with his. I would greatly prefer to post one
.src.rpm file that works on all RPM-based distributions, but of course
reality may dictate otherwise. :-)
David
|
|
From: Jarl F. <ja...@di...> - 2000-12-30 02:48:12
|
On Fri, 29 Dec 2000, David Paschal wrote:
> Hi, Jarl.
>
> Yes, it might be more appropriate to put daemons such as ptal-printd in
> ${prefix}/sbin, particularly as I add more daemons. I'll take a look at
> your attachments later because I can't seem to decode them with the mail
> client I'm using at the moment (not your fault).
Well, maybe a mailing list shouldn't be filled up with attachments in the
first place, so I've put them on:
http://213.237.48.227/~jarl/hpoj/
Notice hpoj is split into the conceptually different parts it contains
It may be down (turned off) some days, approx. every 10th to pick a
number, I'll put them somewhere more reliable soon.
> Timothy Lee has been working on a RedHat SRPM, so you might want to
> coordinate your efforts with his. I would greatly prefer to post one
> .src.rpm file that works on all RPM-based distributions, but of course
> reality may dictate otherwise. :-)
from what I can see RPM is not designed for that feature, in the SPEC file
part of the src.rpm you specify where to put files, i.e. SuSE put libs in
/usr/lib/ wheras RedHat puts them in /usr/local/lib
But from one spec-file it shouldn't be a big problem to make the other.
rename Suggestion:
What about using the name POrTAL (or just 'portal') for the concept now
know as ptal, POrTAL could be for Peripheral Oriented Transport
Abstraction Layer or something else with O, or did you get 'ptal' from
somewhere else? POrTAL is a little bit more pronounceable than ptal.
Jarl
|
|
From: Robert G. B. <rg...@ph...> - 2000-12-31 01:40:46
|
On Sat, 30 Dec 2000, Jarl Friis wrote:
> On Fri, 29 Dec 2000, David Paschal wrote:
>
> > Hi, Jarl.
> >
> > Yes, it might be more appropriate to put daemons such as ptal-printd in
> > ${prefix}/sbin, particularly as I add more daemons. I'll take a look at
> > your attachments later because I can't seem to decode them with the mail
> > client I'm using at the moment (not your fault).
<deleted>
> > Timothy Lee has been working on a RedHat SRPM, so you might want to
> > coordinate your efforts with his. I would greatly prefer to post one
> > .src.rpm file that works on all RPM-based distributions, but of course
> > reality may dictate otherwise. :-)
>
> from what I can see RPM is not designed for that feature, in the SPEC file
> part of the src.rpm you specify where to put files, i.e. SuSE put libs in
> /usr/lib/ wheras RedHat puts them in /usr/local/lib
Actually, RH puts everything in /usr and nothing at all in /usr/local.
It is also straightforward to build a relocatable RPM if nothing in it
needs an absolute path. The only tricky part that I can see of an RPM
is deciding where to put the kernel modules, which generally need to be
built "just" for the kernel they are intended to run under. For the
daemon this won't matter, and I agree that it should go in /usr/sbin and
not /usr/bin. Or more practically, in ${prefix}/sbin.
If anybody needs/wants it, I can contribute a matching "generic
template" specfile and Makefile that do a gangbusters job of building
rpm's in userspace. That is, everything is done by make targets -- make
tgz builds a spec-ready or build-ready whatever.tgz and make rpm builds
a very nice rpm, all automagically, with version/release numbers defined
only in the Makefile.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rg...@ph...
|
|
From: Jarl F. <ja...@di...> - 2000-12-31 02:47:14
|
On Sat, 30 Dec 2000, Robert G. Brown wrote: > Actually, RH puts everything in /usr and nothing at all in /usr/local. I learn something every day :-) > If anybody needs/wants it, I can contribute a matching "generic > template" specfile and Makefile that do a gangbusters job of building > rpm's in userspace. That is, everything is done by make targets -- make > tgz builds a spec-ready or build-ready whatever.tgz and make rpm builds > a very nice rpm, all automagically, with version/release numbers defined > only in the Makefile. That sounds really nice, thanks in advance, I am interested. Jarl |
|
From: Robert G. B. <rg...@ph...> - 2000-12-31 06:19:13
|
On Sun, 31 Dec 2000, Jarl Friis wrote: > > If anybody needs/wants it, I can contribute a matching "generic > > template" specfile and Makefile that do a gangbusters job of building > > rpm's in userspace. That is, everything is done by make targets -- make > > tgz builds a spec-ready or build-ready whatever.tgz and make rpm builds > > a very nice rpm, all automagically, with version/release numbers defined > > only in the Makefile. > > That sounds really nice, thanks in advance, I am interested. See the attached project-0.1.1.tgz project template. It is an autodescribing "standard project" template except for little things like not using autoconf (which I think of as overkill for simple projects). Read the README and look over the Makefile and specfile. With a little bit of setup you should be able to type: make (to make the binary) make tgz (to make a tarball) make rpm (to make source and binary rpm's) as well as (if you like) make cvs make sync to force checkins and/or checkins followed by an rsync to a foreign cvs tree. As well as sundry other make targets. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rg...@ph... |
|
From: Robert G. B. <rg...@ph...> - 2000-12-31 06:20:23
Attachments:
project-0.1.1.tgz
|
Oops, helps if I actually attach the tarball...;-) rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rg...@ph... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X