[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making packager-friendly software
- To: ports_(_at_)_openbsd_(_dot_)_org
- Subject: Re: making packager-friendly software
- From: Jacob Meuser <jakemsr_(_at_)_jakemsr_(_dot_)_com>
- Date: Tue, 3 May 2005 20:29:34 -0700
- Mail-followup-to: ports_(_at_)_openbsd_(_dot_)_org
On Tue, May 03, 2005 at 12:19:01PM +0200, openbsd_ports_(_at_)_inglorion_(_dot_)_net wrote:
> > Very nice paper. Point any software author who doesn't know what
> > they're doing (and we've had a share of that) this way.
> Good paper indeed. Most of it is not even really specific to making
> software packager-friendly, but just general good practice if you
> want to make your software usable to others.
> It raises an interesting point, that I think merits further discussion.
> As the author rightly notices, many problems stem from the fact
> that developers are not packagers themselves. Now, I maintain that
> the reason for this is that packaging is difficult, and unnecessarily
> I must say I like OpenBSD's ports system. It does most things just
> the way I like them, and porting software is often a matter of just
> creating a Makefile with the right variables in it. Simple enough.
heck, OpenBSD ports system is an IDE ;)
the new partial-* package magic kicks ass!
> The problem is, it's only one of many systems out there, and they're
> all different (the nice thing about standards etc). Pkgsrc, for
> example, installs files to their final destination before (optionally)
> building a package, rather than installing to a fake root, building
> a package, and installing that. Packaging for most Linux distros
> is wildly different. I don't even know how to package things for
> This, I think, is why developers don't package. It simlply adds too
but as you said, this is really just "general good practice". if
a package system targetting free software does not leverage
common aspects of it's target, and it has no mechanism for dealing
with oddball quirks, well, what's the point?
why does it matter if one system "fake installs" and the other
installs directly? this is easily accomplished in most cases
with enviroment/make variables. it's really only a problem when
the developer doesn't follow "general good practice".
and if the developer would just take the time to know what issues that
exist with creating packages _for the system they use_, they would
probably be aware of the issues other packaging systems have to deal
> much complexity, and is generally better left to those who know the
> packaging system their system happens to use. And the incompatibilities
> between packaging systems make it hard (if not impossible) to prepare
> your sources in such a way that they work well on every packaging
> system out there.
yes, you cannot defend against all possible shortcoming of all
packaging systems, but you can stick to "more or less standard
GNU autotools" behaviour/expectations.
Some of them will want you to install configuration
> files to /etc, others will want you not to, some will pass you a
> variable indicating where they want something, others won't, etc.
then they should just document how to build the software, for the
packagers ;) or better yet, make a package for the system it was
> I think pkgsrc is on to something with their approach of providing
> an infrastructure that works on a diversity of systems. Unfortunately,
OpenBSD ports system is mostly just Makefiles, shell and perl scripts.
it might take some things for granted (like where perl is, where
are the Makefiles, etc), but pkgsrc probably needs a bit of configuration
(where is perl, where are the Makefiles, etc) when it's installed.
> I imagine most systems won't be willing to abandon their established
> packaging systems. Still, coordination is the key to success. If
> we can at least standardize the way that packaging systems communicate
> their desires to the build process, both developers and packagers
> will have easier lives.
while the GNU autotools may be unpopular garbage, they have created
what some feel is "standard".
now, one thing that people also seem to feel is "standard" or "expected"
behaviour of configure scripts, but in the end is bad practice, and I'm
glad the author mentions it, is "automatic decisions".
when I rewrote transcode's configure script to have support for most of
the 20+ optional packages off by default, there was quite a bit of
resistence. most people just don't think things through, and want
things as "automatic" as possible, without realizing that they're
shooting themselves in the foot.
but I didn't get any negative feedback from package maintainers :)