DSL Ideas and Suggestions :: Filelist w/ .dsl and .tar.gz packages to uninstall

As far as customizing, i was talking about compile-time options rather than changes to the source code.

For example, a pre-compiled application might require a different version of a lib found in DSL. As far as I know the only way to deal with this is to include the redundant library in the package. Usually compile-time options will allow you to specify what lib to use...if the program will still work with the different version, you've saved yourself some filesize.

You can sometimes also disable the use of some libs when compiling, to prevent the need for stuff not needed or available in DSL.

Quote (mikshaw @ Sep. 02 2005,15:38)

But personally i don't really see that compiling a program to run in /opt is much more difficult than building a .dsl from a .deb, and that extra work is outweighed by the added ability to more easily strip down the program and customize it for use in DSL.

Sure... easy for DidiWiki maybe... but XFCE... with many dependencies and 20 odd different modules to be compiled in a certain order... not saying it's "hard" once you get down to it and have some groove going, but I know it was sure faster to build an XFCE package by extracting 20 debs that aptitude told me were required and removing extaneous files than by compiling XFCE by hand...

Different constraints for different people... dial-up, knowledge, processor speed, any number of factors that might make compiling from scratch a real headache for some.

Just explaining why I don't like that stock answer "source is so easy". :-)

Quote (ke4nt1 @ Sep. 02 2005,16:15)

The /opt/bin and /opt/lib option has been discussed before.
But there are still some challenges , even with that in use.

Depending on the program, some applications during the
duration of their execution , STILL insist of finding
needed things in certain locations..

I don't know what the /opt/bin and /opt/lib discussion is about but my thought is to extract an entire non-recompiled UCI into say /opt/package/root... and under root you would find bin, etc, lib, usr etc... then a post instal script soft links the correct locations in the filesystem to the /opt locations... doesn't matter if the program is looking in certain locations, the files will be there because they will be linked...

Quote (ke4nt1 @ Sep. 02 2005,16:15)

A post-install, and post-uninstall script would seem unnecessary,
if the extension and application is assembled and compiled properly..
Any configuration needs can be handled within the wrapper at execution time..

This is hard for XFCE, where my goal is for it to be installed on a CD and to automatically boot, replacing Fluxbox... to do that it replaces .xinitrc in /home/dsl... if there was a postinstall script I could warn the user, make a backup (my preference), ask a question, etc... that's currently impossible... either it cannot be automated and the user has to do something manually or you simply overwrite the .xinitrc... a post-install script would provide some much better options.

I've even thought of creating a DSL just to add post-install script functionality to DSL... does that mean I'd be viewed as an evil child?

I'm confused as to why a post-install script is any less secure than a wrapper if someone is theoretically auditting such things in the first place...

Quote (ke4nt1 @ Sep. 02 2005,16:15)

Since DSL doesn't allow custom code in the extensions,
this seems kinda moot anyway ( excepting the wrappers )

Second time I've heard this... what does this mean exactly? Is there a written policy somewhere explaining practical application?

Quote (ke4nt1 @ Sep. 02 2005,16:15)

User created scripts and executables make me nervous, anyway,
from a support and/or 'source code available' point of view..

I think a policy not unlike Debian's (though I claim to be no Debian policy expert) requiriing certain licensing and source code availability isn't bad at all... I wouldn't want some blackbox code running either... but if it's plain text... or if it's compiled code with available source... I don't see such a problem.

And the fact is someone submitting any package that includes binary files and you have not built it from source yourself... how do you know anything about that package? My XFCE package could format your hard drive after 30 days (rest assured, it does not)... unless (like Debian) you start with pristine source, a small patch, and do the compile yourself you're still open to all sorts of security breaches.

Just my $0.02.

I completely agree with that last bit....it would be very easy to just say it was an official debian package converted to a dsl, when in reality it was modified source and compiled into a dsl package. In addition to this, there is no assurance that it would be taken from an "official" debian package anyway....just like there are myDSL packages available that are not a part of the official repository. I guess what it comes down to is trust, because there's no way you can be 100% sure unless you take the time to explore every function and feature of every dsl package....an impossible task, especially for one person.

For the post-install script, while it would be more convenient for the maintainer of the package, there is NOTHING you can do with a post-install script that you can't do with a wrapper....they are both shell scripts which run prior to running the program, so there is essentially no difference. The only difference I can see is that with a wrapper you would need to first check whether or not the commands have already run to avoid redundancy and possible collisions.

Quote (mikshaw @ Sep. 02 2005,22:52)

there is NOTHING you can do with a post-install script that you can't do with a wrapper....

Except for backing up .xinitrc before replacing it... you fail to acknowledge my one valid example... I'm sure there are others, just I haven't got to them yet. :-)

Next Page...
original here.