Is it better to include dependencies or not?

[battleshooter]

Every time I put together a particularly large package with a lot of dependencies, like KDE4 or Cinelerra, I'm torn between creating them as one large package with dependencies included, or separately so the user doesn't have to double up if they already have different versions of the same dependency installed.

The way I see it is,

Dependencies included:

• -Convenience, one click install
  -The dependencies included are known to work

Dependencies packaged separately:

• -Minimizes risk of clashing with user's preinstalled dependencies
  -Less for the user to download

What's everyone else's opinions on this? Is it better to include all dependencies together or separately? Or is there a middle ground solution that would also work?

[Flash]

Definitely include the dependencies, unless they make the final result huge. Memory is cheap enough, and clock speeds so fast, that it no longer makes any sense to try to save a few megs.

It's a productivity thing. Better a few megs that just work when you click on it than 10K that requires days of searching and trying to get it to work.

[Lobster]

I agree with Flash.

Operating System base programs = small, efficient, code re-use
Added software = convenient for end users.

For example Openshot needs Python and ideally Blender.
Do I want to install devx or look for the latest Python and then go Blender hunting? Clue = no!
So I prefer an SFS if I can find it . . .

The trick is to use your own experience.
Imagine using an 'efficient' mobile smart phone that asked you about installing 'dependencies' . . .

Hope that is realistic and pragmatic

[aarf]

Îf it is a really big pet package I would use a new pupsave so all dependancies would be prefered.
It it were a sfs package I would test it with my current pupsave if there were clashes I would do a pfix=ram . So perhaps split the sfs into logical stand alone seperate sfs and note what is needed to run it somewhere. If it is big it should be a sfs not pet so I go for stand alone split sfs and seperate big pet so then the user can choose what suits their needs.

[battleshooter]

Thanks for all the responses guys!

Hmmm, interesting. I'm surprised all the comments were for packaging dependencies together.

The thing is I usually package quite larger applications so adding dependencies or not can be a difference of 200mb and make up more than half the package.

A large example would be Kdenlive and Amarok2. They both use KDE-Support, KDE-libs, and QT4. To make things simple and encourage people to use Kdenlive, I'd like to make it a one click install package, but then if I packaged Amarok the same way, I would be doubling dependencies in a massive way.

I suppose though in that case it would be better to separate the KDE dependencies and then package Amarok and Kdenlive separately. I suppose as Lobster says it comes down to experience and what seems best to the packager. I guess I was hoping for with this thread was some alternate suggestions besides my own thoughts on the issue, but the feedback so far has been helpful in clarifying my own thoughts.

[pemasu]

If you have upgraded the libs by your own compile, include them definitively to the build.
About duplicating, yeah, difficult thing. You could try to create generic KDE pet/sfs, QT pet/sfs, dependent libs somehow as they are needed for those apps. And so on...

I think that creating dependencies to the pet.specs for your apps would be huge effort.

If people are afraid of libs overwriting, then the sfs is just fine for them. Sfs loading does not overwrite existing stuff, so previously installed libs and so on will be preserved.

I have created gstreamer-and-dependent-libs pet and vlc-deps-pet for vlc but I have packaged qt separately.
In pet.specs there is for vlc: +qt+vlc-deps-dpup

Yeah it helps when you have own puppy-exprimo repo. PPM reads that and installs the dependencies automatically when you check the dependencies.

[01micko]

There's one solution which I have used, mainly because some later libs may be the same as installed libs and overwrite them. You can install libs to a non standard path, then write a wrapper script to kick off the main app including the new path in the LD_LIBRARY_PATH. Works for sfs or pet. Remember, in an sfs the layer is lower than the save layer so a user may be very confused why an app don't work, in fact an old lib may be hiding the intended lib for the program.

I am of the opinion an sfs is better for "one size fits all" and you can include as many deps as you like. With pets,on the other hand, there is always the risk that if a user uninstalls the app the libs come with it, possibly damaging the system.

It's an area to tread carefully.

[Lobster]

Now that some smarter dogs have taken an interest in this thread . . .
Is there any mileage in a pet3 (or appet format) or in fact is the current SFS more than sufficient?

I will mention again that I think we will have to accommodate Android App compatibility in the future . . .

Posting this from Raspberry Pi SAP Alpha1 using Chromium incidentally

[aarf]

[scsijon]

I wonder if some of the 'extra smarties' we DO have in our puppy world, could get together and write a new Applet-format Shell for Puppy, so that we could use apps from Android, Rasberry, and the like directly in Puppy. ?No, you would still have to compile them for the platform, but not also re-write them for the differances, I think.

Now that would be a blast!

Apologies to Battleshooter for continuing the OP'ing of his thread, but I think maybe this is worth persuing and should have it's own thread, ?maybe under Cutting Edge, what do others think? Who, would be available to lead? I wonder if J-M would be interested in the concept?

[aarf]

[battleshooter]

Apologies to Battleshooter for continuing the OP'ing of his thread

That's alright, I think this thread has served its purpose and put out a few different packaging ideas.

@pemasu

Yeah, creating separate SFSs for major dependency groups is probably what I'll end up doing. The only thing I don't like about SFSs is people with full installs don't know what to do with them most of the time I guess I'll have to start teaching people how to use SFS grabber every time I post an SFS.

@01micko

That's an interesting solution Micko, using a wrapper script, haven't thought of that before. I suppose though it could become a waste in the end to have Amarok and Kdenlive both with their own KDE libs running from their own folder, but I see what you mean and a wrapper solution could definitely come in handy for different circumstances.

[Lobster]

Apologies to Battleshooter for continuing the OP'ing of his thread, but I think maybe this is worth persuing and should have it's own thread, ?maybe under Cutting Edge, what do others think?

Pet2 / Android app compatibility thread in cutting edge
http://www.murga-linux.com/puppy/viewto ... 515#632515

[Flash]

See here for CDE, a possible solution to dependency hell.

[Jasper]

Hi Flash et al,

CDE seems really interesting, but after listening to two of the talks by the developer, he says it will usually run quite slowly and needs a target computer made in the last 5 years or so.

It seems it is intended to run specific programs/scripts (which can be amended) from any Linux OS rather than general applications (e.g. LibreOffice)?

I wonder, as a test, could something very small from say, Wary Puppy run on
the RaspberryPi? Or perhaps something from Racy or Knoppix run on Slacko?

My regards

[anewuser]

If one of the problems of windows is DLL HELL, linux has its own twin brother separated at birth, dependency hell.......awww.

Include dependencies, even if in a non standard path so not to break other applications.