[plug] Fwd: packaging idea

John Knight anarchist_tomato at hotmail.com
Thu Oct 17 19:54:31 WST 2002


G'day all!
I've already spoken to a few people about this, Harry McNally and the bloke 
from KDE Usability (sorry mate, I'm shocking with names) spring to mind, but 
I thought it was about time I put it on the mailing list to get some 
feedback. This is just a short intro to the mechanics behind the idea, if it 
were really long, no-one would read it, but I'll let you guys read it first 
and if you can give me some feedback on it, that'd be great. I could also 
explain further and give answers to problems you may have. Either way, it's 
an idea, and it has to be given to the world so I've got something else to 
ponder when I'm in the think-tank! ;)
Cheers! :)
John


Make lunch, not war.

>
>G'day!
>
>I'm probably going to miss a whole heap of info that I would've meant to 
>have written down, but either way, I'll give you the basic details.
>
>The idea is that it's based on everything being public and private, which 
>unix already is, but most people don't take advantage of this versatile 
>fact.  When the user has a package, they open a singular file with a 
>package icon, just like they would on any other GUI based OS. When it's 
>opened, it runs a package installation programme, which has a splash screen 
>displaying the name of the programme you're installing (which would be done 
>by simply having something like <h1>Du Riechst So Gut</h1>). At the next 
>screen you have the option of installing the package privately or publicly.
>
>When you install the package publicly,  you require root privileges, so it 
>prompts for a password, the installation's results after a public 
>installation is basically the same as what happens with an .rpm or .deb 
>file, with a few extras involved. With a private installation, the package 
>installs the files under something like ~/src/(bung all the files in here), 
>either way, the dir name doesn't matter, provided it's in ~. A public 
>installation is something that all users can do, a private installation is 
>obviously only something one user can do, which doesn't require root 
>privileges.
>
>The file placement would be able to work on nearly any system,  as it would 
>only require a base installation, it would be able to run over the top of a 
>system (allowing and distro to run it). In order to make a package for it 
>(let's call it kpm for shortness' sake), a .kpm would have to stict to a 
>strict directory hierarchy, probably the best way to would be to comply 
>with Debian standards. For each file in the package, it would have a 
>[prefix] at the start, as far as its installation path goes. When you 
>choose public, the [prefix] would probably be something like /usr/bin, 
>under a private installation, it would be something like ~/src/bin, 
>depending on the type of system used.
>
>After the file installation, there would be the menu integration section, 
>the next step, which also follows public and private rules (it all does 
>really). It would have a menu integration process similar to Windows, due 
>to Windows having a good method of menu integration, but improved for KDE 
>of course. ;-) When a public installation occurs,  the person installing 
>the programme has the option to integrate the entry into the default menu, 
>that all users have their base on, or simply installing it to their own 
>menu. A private installation would of course only have the option of 
>installing to your own menu.
>
>That's about the basic gist of it, something like GNOME 2's registry 
>feature being used in KDE and integrating that in would be a good idea too, 
>but you have to eat an elephant in small chunks...... ;-)
>
>John Knight
>KDE en_GB (British English) Conversion Team Co-ordinator
>Noah's Ark was built by amateurs, the Titanic was built by professionals.
>Linux vs Windows

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



More information about the plug mailing list