vsido repository

[Digit]

i think this discussion (and repo) is overdue.  so i'm starting it (the discussion at least).

we should get a vsido repo, or two.

... there, it's started.

[VastOne]

All right..  First and obvious question, is what would go in it? 

I have really really really tried to keep VSIDO as generic and minimal as possible.  All of VSIDO resides in /etc/skel, some packages in /etc (changes from debian that identify VSIDO and not debian as the distro), the basic tools in /usr/local/bin (launch, smxi stub etc etc) and the welcome-script in /usr/lib

I do not mean to say this is not important but can anyone tell me what putting up and managing a VSIDO repo will get any current or new user that has not already been provided up to this point?

I am completely open to starting and managing anything so long as it is not a major pain in the arse to do it.  I encourage feedback on this, please

Thanks ...

[PackRat]

I've actually thought about this - but I don't really see the usefulness unless you're planning to fork/provide applications that won't be part of the default install. Be more like a PPA in that scenario, I suppose. I don't think you have the critical mass of user provided scripts/deb packages to justify it.

[VastOne]

The ones that come to mind are:

tint2 which is installed but not the default... It can be made into a package but I see no need to when the development of tint2 is deader than hell... All I did was take patches that should be a part of the package and implemented them, they are freely available on the tint2 configuration / issues site

remastersys which is just a removal of things that I think  is not needed from the original script and tweaks specifically for the VSIDO installation.  This code is already on every installation of VSIDO

The dmenu work that statmonkey did... But I think his improvements are being brought in upstream ...

Other than those, everything is just /etc/skel work and scripts in /usr/local/bin which is also a default to everyone one a VSIDO install

[statmonkey]

I would agree that we probably don't have a base broad enough for this at the moment, all though this does tie in with the systemd stuff in the sense that if you were to go another direction it would be useful.  I too have been thinking about this and came to the same conclusion that unless we fork a great deal there is no value.

BTW the dmenu stuff that I thought would be taken care of upstream is not.  The last build from the dev was still missing some key stuff (xft built outside as an alternative, etc.) so not sure I will count on that.

On my to do list is still to upload several scirpts on here, the mpd stuff especially and a couple of dev forks I have been working on that the devs on those have said "good stuff" we will implement it next year or so.  My problem is that horse racing season for my horses starts in a couple of weeks and I will be even slower after the ponies are running.