[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

debian packaging and /usr/local/bin



Recent discussions about netscape and other non-gpl applications prompt
me wonder about the debian packaging system.  In most unix systems software 
that is not part of the distribution is compiled and put into /opt 
or /usr/local or some similar place. Usually developers will have make files
for one or two  unix versions.  More recently, I have seen .config scripts 
that will create the make file for you after scanning the system for
information about PATHS, compilers, libraries and other jazz.  This information
can also be obtained interactively from the user.

Now if we are concerned about administrators being able to  keep all 
applications in the dpkg database, so as to insure system integrety, could
not some kind of generic .config script be written that creates .deb files
for non-supported applications.

Actually I think some sort of wrapper program for creating debs would be
very useful for upgrading applications that are part of debian. Really why
should someone have to wait for a new deb file to be created by a debian 
developer if the application itself is actually already available?  Many
applications in stable are many many versions behind. A configuration 
script of the kind I am suggestion would allow a novice admin to easly
upgrade and maintain their systems. The fact that we are over a year between
releases suggests that original package maintainer-user relationship may 
not be practical in a world with thousands and thousands of linux applicaition.

I am writing this from the perspective of an administration not a developer.
I would not know to create the kind of deb creation and configurtion script
I am describing.  (I mention this to avoid the kneejerk "good idea why don't 
you write it" response)  

I just wonder if this is a practical solution to installing non-gpl
applications that would also help keep debian more upto date without
users being totally dependant on our excellent, but obviously overburdend
development team.  Does any of this make sense?




Reply to: