A better apt...
After thinking about ways to have a more intuitive way of adding and
removing components and reading up on the design document in the apt
package I have decided that the addition of several tags to the
control file would add a lot of potential to really making a killer
apt that will out due all other package managers, one that would be so
good that Red-Hat might just abandon theirs.
>From reading the design documents and what I gather from talking to
various people it looks like apt will support keywords to aid in
finding packages and will be able to install packages based on the
intended end use much like Red-Hat does.
However, that to me is not nearly enough. Although keywords may aid
in finding packages there are a crude method for doing so. I want
something more. Here is what I propose....
1) The addition of a function tag which will decide the function(s)
of the package.
2) The addition of an interface tag will describe the interface of the
packager such as command-line, ncurses, X, lib, doc, etc...
3) The addition of a way to group packages such as xxx-base, xxx-doc,
xxx-dev together into one group xxx.
#1) the function tag will describe what exactly the package does in a
standard manner. The tags will be organize in a tree like manner
for easy browsing.
For example gs might have a function tag like this:
function: view/ps, view/eps, image/view/ps, image/view/eps
And say ncftp would have one like this:
function: net/ftp
And say mctools-lite
function: media/cd/play, /media/mixer.
Although keywords will serve a similar purpose the are not quite as
nice and would be difficult to standardize. On the other hand it would
be fairly easy to come up with a standard set of function tags and also
to come up with polices of how to add a new function to the tree.
Also keywords are generally single words with out any sort of grouping
while the function tags are organise in a tree like manner. This
means that the future package version can have an option of a function
browser to allow the user to easily find what there are looking for
and then only get a result.
For example suppose a user is looking for a good program to view gif.
So they chose the keyword of gif and this yields:
giftrans
libtiff3-gif
xv
libgd1-dev
libgd1
zgv 2.7-4
xloadimage 4.1-2
xjig 2.4-1
As you can see a lot of this is not what they want. Now they can
narrow there search but which keyword should they chose (viewer, view,
browse) etc... However this relays on the package maintainer choosing
good consistent set of keywords. And it is also a pain to do,
especially for new users.
Now with function tags they will open up a window to browse the tree.
Select image, then view, then gif, and instantly the following
packages are chosen
xv
zgv
xloadimage
Now to me that is a heck of a lot better.
The difficult part will be working out the details of what the three
should look like however once that is done it should be trivial for
package maintainers to use (compared to getting the dependices right and
such)
#2) The interface tag is similar to number one but will instead
describe the interface of the program such as command-line, full
screen curses bases, X, SVGA, etc..
This would be useful for eliminating packages for interfaces that you
can't/don't want to use. For example if you eliminating X as a
possible interface you would be left with the "zgv" package.
This should be fairly easy to both standardize and implement.
#3) The last and final proposal is to prove a way of grouping packages
together that are really the same program.
It will server to make the package list look a lot cleaner as
something like:
xemacs20-bin 20.4-5
xemacs20-mule 20.4-5
xemacs20-mule-canna-wnn 20.4-5
xemacs20-nomule 20.4-5
xemacs20-support 20.4-5
xemacs20-supportel 20.4-5
Would all be collapsed into a group called xemacs20. The group would
just be a package with nothing but a control file to describe stuff
that is common among all the packages such as the description of the
xemacs program the, rough version number (20.4), etc... A new tag
called (perhaps) "base-package" in each of the individual packages
will simply contain the name of the base packages in this case it
would be:
base-package: xemacs20
for all of them.
This would keep the benefit of breaking out the unnesseasarly components
with out cluttering up the "high-end" package list. The user of the
package system can naturally expand the base package to chose which of
the components they want....
So what do you think of these ideas? I think if used probably these
would greatly enhance the package system to the point where it would
make redhats RPM system look obsolete.
I would definitely be willing to work hard on the details of how these
three extensions should work and will also be willing to write sme
code where I can.
I am serious about making this work so please don't dismiss this as
just another "wish-list" idea that would be "nice" to have but thats
it.
Thanks,
Kevin Atkinson.
PS: I tried to do my homework as best as I could however I am sure I
may of missed something so please be nice. Also I wasn't sure where
this post should go so I decided to post it to Debian-devel instead of
cross-posting to several mailing lists.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: