Vendor created RPM naming.

[Ace Nimrod]

We provide our product as a set of RPMs for RedHat 4/CentOS 4 (and soon 5)
and we require some RPMs that are upgrades of the base RPMs. To prevent
conflicts we install all our packages in /opt/<vendorname> and prefix all
RPM packages with <vendorname>. This will prevent us from overwriting any
other RPMs, as well as RPMs overwriting ours.

Is this sane?

So for example, we provide our own foobar package which is an upgrade to
foobar in CentOS 4, we'd name it like..
<myvendor>.foobar-1.2.3-1.el4

Is there a better approach to take with this? So far it seems to work just
fine.

Thanks.

[Wichmann, Mats D]

If you felt like justifying your choices by following an actual
published guideline, you could look here
(see in particular the 4th bullet which matches what you're already
doing).

http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-ge
neric/pkgnameconv.html






________________________________

From: rpm-list-***@redhat.com
[mailto:rpm-list-***@redhat.com] On Behalf Of Ace Nimrod
Sent: Thursday, July 19, 2007 11:55 AM
To: rpm-***@redhat.com
Subject: Vendor created RPM naming.


We provide our product as a set of RPMs for RedHat 4/CentOS 4
(and soon 5) and we require some RPMs that are upgrades of the base
RPMs. To prevent conflicts we install all our packages in
/opt/<vendorname> and prefix all RPM packages with <vendorname>. This
will prevent us from overwriting any other RPMs, as well as RPMs
overwriting ours.

Is this sane?

So for example, we provide our own foobar package which is an
upgrade to foobar in CentOS 4, we'd name it like..
<myvendor>.foobar-1.2.3-1.el4

Is there a better approach to take with this? So far it seems
to work just fine.

Thanks.

[Bob Proulx]

Post by Ace Nimrod
We provide our product as a set of RPMs for RedHat 4/CentOS 4 (and soon 5)
and we require some RPMs that are upgrades of the base RPMs. To prevent
conflicts we install all our packages in /opt/<vendorname> and prefix all
RPM packages with <vendorname>. This will prevent us from overwriting any
other RPMs, as well as RPMs overwriting ours.
Is this sane?

Yes. I believe that is very well done and exactly keeping in the
spirit of the /opt directory. Note that existing Unix vendor practice
of using /opt in just this way has been around for a long time.

Post by Ace Nimrod
So for example, we provide our own foobar package which is an upgrade to
foobar in CentOS 4, we'd name it like..
<myvendor>.foobar-1.2.3-1.el4

I think the '.' separator is okay but most packages doing similar
things have previously used a '-' there instead.

Post by Ace Nimrod
Is there a better approach to take with this? So far it seems to work just
fine.

I like it!

Bob