In alt.os.linux.slackware on 11 Aug 2004 12:01:32 GMT
Joost Kremers <joostkremers@yahoo.com> wrote:
>
> yes. and after uninstalling a packages, they go to
> /var/log/removed_scripts (and the package descriptions to
> /var/log/removed_packages).

Oh good.

>
> to overwrite /etc/postfix/main.cf, the package should contain a file
> /etc/postfix/main.cf.new. then doinst.sh can mv the old config file to
> /etc/postfix/main.cf.save and mv /etc/postfix/main.cf.new to
> /etc/postfix/main.cf.

That's what I do now, it's only sensible. I don't rely on the auto
feature of RPM for that, it's not reliable.

> removepkg does do some checking of the relevan doinst.sh script, and IIUC
> removes symlinks created by it. don't know what else it checks and
> undoes. check it out and see if you can use it. and if it doesn't provide
> all you need, you could consider modifying removepkg to run an uninstall
> script.

I figured it would have to be something like that. Either alter
removepkg or run something that calls it.

THe latter probably, altering system software bites you badly. If the
scripts end up in a normal place then I can keep the uninstall and
install together, which makes writing them easier and less liable to
human error. Else make a /var/pkg of my own I guess. GOing to have to
write a bunch of dependency code for some things too...

Makes adminning multiple servers in different countries with various
requirements and a lot of inhouse code a lot easier with good package
management.



Zebee

In alt.os.linux.slackware on Wed, 11 Aug 2004 20:33:36 GMT
Rich Grise <null@example.net> wrote:
> if they save themselves there.
>
> I noticed nobody's mentioned rpm2tgz. It's a script, by Pat Volkerding.
> It says, in part:
>
> You could run this on some of your RPMs, and look at the output, and
> get an idea what a package might look like.

I did. It unpacked the RPM. It
>
>
> But I think you're barking up at least one additional rope here -
> you say that you're setting up and configuring multiple machines
> from scratch, right? If that's the case, what do you need to create
> packages for? Just install everything when you install Slack. Take
> a look at Pat's install scripts - I know there's at least one person
> around here who knows where to find that setup script - and customize
> it.

Because I do a lot of custom config for special purpose servers. I am
not building generic machines, but ones that are quite specialised for
their jobs.

Some things have to be compiled from source, some have to be configured
in various ways. If you are making a plain vanilla box, yes, just load
it all up is fine. I'm not.

> Slack just plain doesn't have the same package problem other distros
> have. That's another one of its advantages. Slack expects its system
> admin to know what he or she's doing.

*grin* Or to have very low expectations, choose the insult that works
for you!

I do know what I'm doing, which includes wanting to automate as much as
possible. And to make sure that the least possible human error creeeps
in when you need to have something running or changed on one of several
twisty little boxen all alike.


>
> But if you make a stable, complete system in the first place, then
> there's no need for package management at all.

Stable and complete is probably what you do when you aren't running
special purpose production boxen, with frequently updated custom
applications. Some bits are stable and complete and I haven't touched
'em in years. Others get updated weekly or more often. I need stable
for the things that are stable, and quickly and correctly updating for
the things that need to be quickly and correctly updated. Most of which
are not things you get in a distro, but inhouse written or configurations,
some of which are constant, some machine specific. But some are, except
usually with special compliation requirements or of versions well ahead
or well behind most distros.

I want to keep the things I don't need to touch as standard as possible,
but be able to manage the things I do need to touch.

>
> But if you're writing software to distribute that runs on any system,
> then you'd want to make a package out of it.

Exactly. With changelogs that are quickly found, with good install and
uninstall, and with dependencies so shooting yourself in the foot is
harder. You can write all that in each script each time, it's painful
though.

So it looks like if I want to use slack, I have to re-invent wheels.

Zebee

Zebee Johnstone wrote:
> In alt.os.linux.slackware on 11 Aug 2004 12:01:32 GMT
>> removepkg does do some checking of the relevan doinst.sh script, and IIUC
>> removes symlinks created by it. don't know what else it checks and
>> undoes. check it out and see if you can use it. and if it doesn't provide
>> all you need, you could consider modifying removepkg to run an uninstall
>> script.
>
> I figured it would have to be something like that. Either alter
> removepkg or run something that calls it.
>
> THe latter probably, altering system software bites you badly.

less so with slackware, i suspect. it's intentionally kept simple. but
writing something that calls removepkg still seems a better option, i'll
admit.

> If the
> scripts end up in a normal place then I can keep the uninstall and
> install together, which makes writing them easier and less liable to
> human error. Else make a /var/pkg of my own I guess. GOing to have to
> write a bunch of dependency code for some things too...

sounds like a lot of reinventing of wheels... have you checked out the
alternative package management systems for slackware, like slapt-get and
swaret? i've never used them, so i don't know what they do and do not
provide, but if you need dependency checking, they may get you on your way
a bit further than the standard pkgtools.

> Makes adminning multiple servers in different countries with various
> requirements and a lot of inhouse code a lot easier with good package
> management.

you should of course always use the best tool for the job. in your
situation it seems worth considering whether the time you need to invest in
slackware to get it to do what you want is really worth it, compared to
continuing to use an rpm-based distro.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Zebee Johnstone wrote:

> Is there any way of querying changelogs except having them in a file in
> the file tree and looking at them?

Yeah, I miss --changelog too.
I was thinking about putting a ChangeLog in my packages' install/
directories. At least that way...

tar -xzOf package.tgz ./install/ChangeLog | less

....would accomplish pretty much the same thing. I guess a bash alias of
some sort would be next to save typing

It's a big adjustment coming over from the RPM side of things. There is
a plus, though. You are trading for simplicity. In my opinion, that's
always better in the long run

> have I been spoiled by RPM and if I want that much control and
> information I should stick to RPMs?

I debated that point for a long time as, at work, we are standardized on
RedHat and I am the one who gets stuck writing spec files.

Eventually, I just bit the bullet and made a tgz install of our project.
It's not so bad. In fact, it's a great deal easier than doing a spec.
Particularly where %files and %install discrepancies are concerned.


--
Tom Wilson
Pascal Users:
To show respect for the 313th anniversary (tomorrow) of the
death of Blaise Pascal, your programs will be run at half speed.

Zebee Johnstone wrote:

> I'm going to be making my own packages for slack to use on my own
> servers. I am currently doing this using RPM on Rh machines, but if I'm
> changing distribution, may as well change all the way.
>
Good Idea. :-)

> The doco's a bit light on... I understand that all I get is a tarball
> and an install file, but there are presumably right ways and wrong ways
> of doing the install file?

I think this has been discussed in some detail. What it boils down to is,
the "right way" is "what works."
>
> have I been spoiled by RPM and if I want that much control and
> information I should stick to RPMs?

Spoiled, yes, but not in the way you think - spoiled like a kid
who gets all the gingerbread he wants, and never knows meat and
potatoes. :-)

<soapbox>
You seem to have the same syndrome I have - you are making way more
of this than you need to. It took me forever to get anything going
when the first thing I did when I unzipped it is start to hack it.
When I quit doing that, I was amazed how simple everything turned
out to be.

I've been following the thread, and I got the one about a forest
of custom boxen. ;-)

Modularize. Give everybody the same kernel and a, ap, d, f, l, and n "disk
sets", with the rest optional at install time. Just like the CD. ;-)
Then, for anything custom that needs to be installed, if it's
a published program, I'd rely on its own scripts and/or installpkg
and/or pkgtool, and for in-house stuff, put out a memo, saying:

"All custom in-house software shall use the following structure:
myprog.0.0.1
- src
- doc

and whatever - there are examples all over the place. And it doesn't
take very long to learn how to do packages, e.g.
http://www.slackware.com/config/packages.php

You can't get around doing some stuff by hand, like sitting down
to install the stuff itself, and making decisions as to what goes
where.

Redmond^H^H^H^HHat has everything all intertwined, so when you change
one thing, you have to reinstall the whole freaking system, like
Windoze. You don't have to do that with Slack. You don't need much
dependency checking, because packages that are written for Slack
don't hack standard libraries and replace them for you.

Oh. There you go - What Not Do Do When Creating A Slackware Package:
Don't customize stock libraries and break everybody else's software.

But I'm sure you get the point by this time - I just wanted to sound
off again. :-)

I think if there's any one keyword that sums it all up, I'd say
"consistency."
</soapbox>

Have Fun!
Rich

If you want to see a bunch of documents on Packages and how why and
when try LinuxPackages. It has everything from the doinst to what
the perfect package should look like. All these guides have been
taken from the Slackware standards in place now.
You can check them all out at:
http://www.linuxpackages.net/howto.php

Message posted via:
=====================
www.linuxpackages.net/forum
www.linuxpackages.net
Expanding the world of Slackware
=====================

On 08-12-2004, in alt.os.linux.slackware,
tg <tg@linuxmafia-dot-org.no-spam.invalid> wrote:

> If you want to see a bunch of documents on Packages and how why
> and when try LinuxPackages. It has everything from the doinst to
> what the perfect package should look like. All these guides have
> been ^^^^^^^^^^^^^^^

The perfect package?... Reminds me of that line "Beauty is in the
eye of the beholder".

(
NOTE: I'm not one that thinks non-distro related third party
bullshit *needs* to be shoved into /usr/ by default. The
linuxpackages "standard" says otherwise.
)

But then, maybe the folks at linuxpackages are pretending to be PV,
in that if PV were to actually latch unto Wine, he'd probably put it
all in /usr/. The kicker here is PV won't endorse wine or any of the
other third or fourth or fifth party software other distros go out
of their way to include now will he? Why exactly does /usr/local/
exist?

Is it a "slackware standard" or a "linuxpackages standard"? Or, more
importantly, is all of this just a "'Max' standard" way of thinking?


Max

--
For every evil under the sun,
There is a remedy, or there is none;
If there be one, try and find it,
If there be none, never mind it.

Max wrote:
> NOTE: I'm not one that thinks non-distro related third party
> bullshit *needs* to be shoved into /usr/ by default. The
> linuxpackages "standard" says otherwise.
[...]
> Is it a "slackware standard" or a "linuxpackages standard"? Or, more
> importantly, is all of this just a "'Max' standard" way of thinking?
>

IMO /usr/local should be reserved for stuff that i compile and install
myself. so everybody that's not me should keep their smelly paws off of
it. ;-)

btw, when i compile something and create a tgz from it, i always put it in
/usr as well. just because it *is* a packages. /usr/local is for stuff that
is not packaged up nicely.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10 Aug 2004 23:03:06 -0500, +Alan wrote:
>
> In alt.os.linux.slackware, Zebee Johnstone dared to utter,
>> The doco's a bit light on... I understand that all I get is a tarball
>> and an install file, but there are presumably right ways and wrong ways
>> of doing the install file?
>
> ./configure

Often good to specify --prefix= and --sysconfdir= on the ./configure
> make
> make install DESTDIR=/tmp/build

Often good to run make -n install DESTDIR=/tmp/build first to see if
the Makefile honors DESTDIR.

> cp $VARIOUS_DOCS /tmp/build/usr/doc
> cd /tmp/build

mkdir /tmp/build/install
create a install/slack-desc file
if needed create an install/doinst.sh of course makepkg will create
a simple one if there are any symlinks in /tmp/build/*

I often gzip any man files, and check ownership/permissions of
files.
> makepkg /tmp/$PACKAGE
>
>> What are good packages to look at to see good practice in building
>> install files?
>
> The SlackBuild scripts on the source code cds.
>

An excellent resource!

I decided to give evolution a try this weekend. I didn't feel right
going the dropline-gnome route, especially since I really don't use
gnome anyway, prefer enlightenment. I compiled and built the packages:
gal-2.1.12-i486-1bgr.tgz
libgcrypt-1.2.0-i686-1bgr.tgz
gnutls-1.0.16-i486-1bgr.tgz
libsoup-2.1.12-i486-1bgr.tgz
gtkhtml-3.1.18-i486-1bgr.tgz
evolution_data_server-0.0.96-i486-1bgr.tgz
evolution-1.5.91-i486-1bgr.tgz
gnome-spell-1.0.5-i486-1bgr.tgz

Except for a bit of a hassle getting gnome-spell to compile[1] it
was a breeze. Have to say I could get used to evolution, it's pretty
nice.

Brad

[1] gnome-spell won't compile with the new version of gtk+2, debian
has a patch that works, gentoo's patch fixes the compile problem but
adds yet another dependency.

-----BEGIN PGP SIGNATURE-----

iD8DBQFBHsj0kDp4KjYna1ARAiVRAJ0d0+oCnWEd7CQBon10wR OZ6SBhYwCfcHR7
XbBH8U7tnPJNdp58mobxHM0=
=5Osu
-----END PGP SIGNATURE-----

Bradley Reed wrote:
>> make install DESTDIR=/tmp/build
>
> Often good to run make -n install DESTDIR=/tmp/build first to see if
> the Makefile honors DESTDIR.

and when doing it for real, keep a log file:

make install DESTDIR=/tmp/build > install.log 2>&1

sometimes DESTDIR is honoured for most of the install commands, but not for
all. sometimes there are commands that are only executed when DESTDIR is
not set. with keeping an install.log you can track these things and correct
them.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)