There is a third possibility. Create an apt-get-able site at javien.com to
hold alpha and beta versions, and get "stable" versions duploaded into
Debian via sponsorship and/or new maintainers.
Tell your customers to apt-get off of javien.com for the latest and
greatest, and dupload stable versions to Debian to get "maximal
distribution", as you say.
I looked at javien's webpage, and it "contains alot of words yet doesn't
say anything". I'm sure once you release, you'll have no problem finding
someone to sponsor, but until then don't expect people to jump at the
chance, sponsors generally sponsor packages they would use, and I can't
figure out what javien does based on the web site, so I have no idea if I'd
use it. If its an open source ebay I might be interested, but if its for
trading pork belly futures I wouldn't care.
You'd earn some good karma points, and prevent problems in the long run, by
giving the "repackaged" packages back to debian. File a few bugs with what
you need changed. Generally not a good idea in the long run to repackage,
if you can avoid it at all:
1) Look at this scenario -> Ver 1.1 of foo is inadequate to support javien,
so javien creates Ver 1.1.1 of foo. Great, for now. Then debian's foo
maintainer upgrades to 1.2, and everyone who installed your 1.1.1 gets it
overwritten with the new 1.2, and now javien doesn't work until you create
and release 1.2.0, not cool. The Helix guys have their own ways of working
around that.
2) I hope you're not repackaging libc or something like that because there
is the other failure mode where your ver 1.1.1 of foo breaks baz 8.1 (and
you don't maintain or use baz 8.1 so its understandable) and then the
Debian developers for both foo and baz get all annoyed that "your" package
is breaking "their" packages, even if its totally unintentional, etc.
3) Another good reason to fix the Debian packages instead of creating your
own, is giving back to community, feel good about going to work.
4) Fixing packages is universally considered to be good, and good PR never
hurts a new company.
5) The final really good reason to get the Debian packages "fixed", is that
once they're permanently fixed at Debian you don't have to keep fixing each
new version of the Debian packages as they're released, so it saves you
time and money.
"Wesley W.
Terpstra" To: debian-devel@lists.debian.org
<terpstra@jav cc: (bcc: Vince Mulhollon/Brookfield/Norlight)
ien.com> Fax to:
Subject: Who should package&host a product?
01/17/2001
11:51 AM
Hi, I work for a company which does concurrent development for *nix as well
as windows. For the *nix version of our project we plan to include the
debian package format in our official release. We've already set up the
building of lintian-happy packages for our software, and I wanted to
enquire
as to the most politically correct distribution scheme.
First, some details about the project:
The software will be released under a license that adheres to the DFSG --
in
fact, our open source license is largely designed to satisfy it. :-)
The project uses some packages that are not packaged in debian and some
that
were inadaquately packaged. We've repackaged these ourselves.
Obviously, we are a commercial company. :-) However, our revenue model is
not selling the software, but by charging for the use of our servers and
databases. Thus we can contentedly make the software DFSG compliant.
Our goal is to acheive maximal distribution. ;-)
Since anyone running debian probably points to a debian mirror, we'd rather
get our packages - and those we depend on - on the debian servers.
So, what is the debian-correct method here?
Should we just keep our packages to ourselves like helixcode was/is doing?
Should we find an existing maintainer to dupload the debs we feed him?
Should one of our developers apply to become a NM?
Thanks for your time, ... and debian. :-)
--
Wesley W. Terpstra <terpstra@javien.com>
Javien Canada Inc. - Linux Developer
(See attached file: attmpgj4.dat)
Attachment:
attmpgj4.dat
Description: Binary data