multiple apps - single .dsl?
Forum: myDSL Extensions (deprecated)
Topic: multiple apps - single .dsl?
started by: mikshaw
Posted by mikshaw on July 14 2004,01:41
I was working on a .dsl today (I'm VERY new to this), and found that the application (bakon) requires an entirely different application (fortune), not just a library or two. I'm wondering if both applications should be included in the .dsl or if fortune should have its own .dsl. The problem with this, of course, is that if you wanted to use bakon, you'd need to download both. I'm not jumping to conclusions because I know some people like fortune who have no interest in a typing tutor.If it were just for myself I'd throw the two together, but I'm curious what others would prefer in case I actually get this to work.
On an unrelated note, what is your opinion of single-file apps in a dsl? Is it worth the bother? What I'm getting at is something like root-tail or gflashplayer, which are self-contained in one file and can be run from anywhere....is there any point in tarring and uploading them?
Posted by ke4nt1 on July 14 2004,02:49
My thoughts would be to have both...a "fortune.dsl", and a "bakon.dsl", that includes fortune in it.
For those who want just fortune, you can get it.
For those who want bakon, you can get it.
This ensures that if the "fortune.dsl" gets upgraded, or revised, that
the version of fortune that "bakon" plays nice with stays with it.
LinNeighborhood contains samba, although you can install samba separately.
Edna contains python (for now) , but you can get python separately.
Many .dsl files contain components that CAN be installed individually, if you wish...
As for the "one file .dsl" that's debatable.....
It's just as easy to install a file thru d/loading or from a cd or floppy copy.
A "one file program" is easy to backup with your filetool.lst/backup,
so it never has to be installed or downloaded again...
(which is basically what the backup.tar.gz file is, a .dsl full of files named backup.tar.gz)
( which is basically what the *.dsl files are, a tar.gz full of files named *.dsl )
---- chicken or egg ? ------
Where I CAN see a "one file .dsl" is where you want to have an icon on your
desktop, or an addition to the start menu, or both, to run the application...
But now your back to a 3 file .dsl , which is a fine addition to the DSL community.
The "themes" .dsl files are 3 file dsl's, and 4 files for the DSL-aterm.dsl, and others as well..
A .dsl file also makes sure the file is installed to the proper location, and with proper permission/ownership, which
may or may not be a problem for new users to Linux and DSL.
I'm sure others will have different opinions, depending on their skill level.
73
ke4nt
Posted by roberts on July 14 2004,05:49
We are growing so fast that we are now discussing dependencies. I think color coding also plays in here.IMHO the one big dsl file that includes everything needed, is not really the spirit of being damn small. Everthing in one dsl extension is the easy way out. But these will probably get a higher risk level.
I think the first step in approaching this challenge is the color coding of the extensions.
Also implementing, as user nucpc, suggested, that we flag those extensions that have dependencies or MUSTREAD in the info files.
Color coding will provide the user what may be expected .Overwriting base system files could impact the integrity of the system. . Do you want to start several versions the same support apps? There goes the small out of damn small.
For extension's supporting libraries and apps, it always best to try to use the base DSL system, if not, then preferred to make the extension run under /opt and via shell wrappers be able to use other extensions. That way, less resources are used.
For now, I think the color coding will hopefully give incentive to package apps under /opt and use dependencies that are also under /opt. Extensions under /opt /home /tmp and other normally user writeable directories will have a "safer" level color than those that call mkwriteable. Actually I am thinkiing of using 4 levels. Even thought all extensions should be viewed as pontenially unsafe, wouldn't you want your app to have a color indicating less of a risk?