[Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I agree that std and soho should be separate and should have separate
repos and I thought I made that clear in my original message - lol.

Live would be Uel's baby so I'll let him address that.  As part of his
live build, he could just strip out the dev stuff but then installing
that would be a pain since you couldn't make packages without having
to download everything.  Folks that need ati or nvidia drivers or any
other proprietary drivers would be SOL.


On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> hi, am sorry i could not be part of the irc conversation. But may i sugge=
st
> that we should consider the live versions also from the start?
> the key would be to start with a really simple base.
> here is the layout i have in mind[ very awkward.. but might work.. change=
s
> invited :) ]
>
> 1. Dev base
> 2. Non Dev base [ for the minimal live CD ]
> 3. Std [ 1 +  no kde - soho apps ]
> 4. SOHO [ 1 +  kde + soho apps ]
> 5. Std Live [ 2 + * ]
> 6. SOHO Live [ 2 +  kde + soho apps ]
>
> i agree that our primary objective for SoHo should be kde only. if there =
is
> a lot of demand for other WMs, that should be an additional package.
> what we release should be usable .. for example puppy linux uses VL as th=
eir
> host development system.   But their install is simple and clean.  We can=
 do
> a similar thing.
>
> commonly pooping up themes :
> 1. upgrade path from std to soho
> 2. --dist_upgrade
>
> If we ignore one 1. have two clearly demarcated repos for std and soho . =
2.
> is possible
>
> And it makes development and package management a lot easier if we consid=
er
> them two seperate Distros altogether.. they share only the vector
> philosophy.. and the non KDE part of the initial base system.  All packag=
es
> that can take advantage of having KDE as a dep should  have it .
>
> Life will be much much easier for ever one involved, devs, pkgers and use=
rs
> :)
> cheers
> ram
>
>
>
>
>
> On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> > On 4/6/06, uel archuletta <ue...@gm...> wrote:
> >
> > >
> > >
> > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > >
> > > >
> > > >
> > > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > >
> > > > > Sounds good. I have some additions to a few of your propositions.
> > > > > here thay are
> > > > >
> > > > > 1. we have some package list we may be able to use to help in thi=
s
> > > > > they are in ftp in the VL6base folder.
> > > > > 2. I nominate you to build the base and get it setup for us. :)
> > > > >
> > > >
> > > >  OK
> > > >
> > > >
> > > >  3. sounds good, but do we have enough people to seperate into 2
> > > > > groups?
> > > > >
> > > >
> > > >  If not 2 groups, then each dev can have 2 partitions for dev - std
> > > > and soho. This shouldn't be too bad a task if we have all the pkgs
> decided
> > > > upon at the beginning and hand out the workload equally. Remember, =
in
> the
> > > > past Robert did std by himself and I did soho by myself on top of s=
td
> so it
> > > > is possible.
> > > >
> > >
> > > That is workable 2 seperate workloads if one has time/space they coul=
d
> > > work on both.
> > >
> > >
> > >
> > >   4. agree
> > > > > 5. agree
> > > > > 6. I along with others would like to see this borken down further=
.
> > > > > base-cli, dev, X, std, soho, some examples would be the package
> lists in
> > > > > VL6base on ftp.
> > > > >
> > > >
> > > >
> > > >  base-cli and dev will have to be 1 since we can't work on a base
> > > > without dev tools.
> > > >
> > >
> > > this is where I get things mixed up so correct me if I am wrong. if w=
e
> > > are building packages and populating a repo then we can build a base =
for
> the
> > > devs to build packages on that has all tools and X, and then build a
> base
> > > for the installer that has them seperated out. as long as we test the
> > > packages on this base as well.
> > >
> >
> >
> > I think this would create more work.  Apps built for SOHO would have
> > kde-centric additions wherever possible to integrate them better into t=
he
> > desktop environment. While we may use the same apps for std, they shoul=
d
> not
> > have kde deps in them.  This is kind of like the issue you get if you t=
ry
> to
> > install packages from linuxpackages.net - arts has a dep of gnome - wtf=
?
> > Whay would you build arts with a gnome dep. Same goes for apps for std
> that
> > might have a kde dep - not a good thing at all.
> >
> > The base would be common to all, including X and dev.  std(WM's and
> > apps) and soho(KDE and apps) would then be built on top of the base.  S=
oho
> > would have KDE as its first build so that any other app installs after
> that
> > would be able to use kde hooks where needed.
> >
> >
> >
> > >
> > >
> > >   X - if by this you mean xorg alone then I agree but if this include=
s
> > > > WM's,etc then no.
> > > >
> > >
> > > Vec asked if we couldnt include xfce in our xorg package since it is =
in
> > > both, and if we go down to the package level it woould simply mean
> adding it
> > > to the metapackage
> > >
> > >
> >
> >
> > I really don't think xfce should be in SOHO.  IMHO, 99% of those that g=
et
> > SOHO are getting it for kde and not xfce.  If they want xfce, they shou=
ld
> > stick with std.  This would also allow us to make soho easier and bette=
r
> due
> > to the fact that you wouldn't have to worry about menus and such as lon=
g
> as
> > a kde .desktop file was included with the packages.
> > Folks that are looking for xfce aren't looking for the bloat of kde and
> > those looking for the richness and integration of kde aren't looking fo=
r
> > xfce.  Again, we need to go back and look at the target market for thes=
e
> and
> > not what we want out of it.  We could always add wm's and such to the r=
epo
> > but I doubt they'd get a lot of hits.
> >
> > Concentrating only on kde for soho would be the best bet.  choosing app=
s
> > for soho should also be centred around kde as well so they integrate
> > properly into the DE.  The maturity of the apps for kde is there now an=
d
> we
> > should take advantage of that.
> >
> > The only folks I know that run SOHO with xfce are vec and monty - lol. =
No
> > offense guys.
> >
> > We need to focus on packages as that is what is really important. That =
is
> > why stuff like ubuntu, gentoo,etc have gained the popularity they have.
> > Folks don't have to go searching a million different places to get what
> they
> > need. It is all available from a central source for the most part.
> >
> > Linuxpackages and slacky.it are ok but they still have some goofyness t=
o
> > them with deps of stuff that isn't needed.
> >
> >
> >
> > >    7. I think there should be a seperation in release dates. 1 reason=
 is
> > > > > Distrowatch another is easier for us to debug.
> > > > > 8.agree
> > > > > 9.agree
> > > > > 10.agree
> > > > > 11. see #7
> > > > > 12. I really like this idea
> > > > > 13. agree
> > > > > 14. agree
> > > > >
> > > > > some really good ideas here Tony.
> > > > > Thanks,
> > > > >
> > > > > Uel
> > > > >
> > > > >
> > > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > > >
> > > > > >  Sorry if this has already been decided upon but I haven't been
> > > > > > made aware of it so here goes.
> > > > > >
> > > > > > I have been looking at these as I'm sure some or all of you hav=
e
> > > > > > as well.
> > > > > >
> > > > > > I think we can work with these to build our base from source an=
d
> > > > > > then expand on them in the future.
> > > > > >
> > > > > > There were a few of us on irc last night chatting about it.
> > > > > >
> > > > > > This is how I think we should move forward with this:
> > > > > >
> > > > > > 1 - as a group, decide on all the packages for both std vl and
> > > > > > soho before we start
> > > > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l=
/k
> > > > > > source trees) - probably either myself or Uel or anyone that wa=
nts
> to take
> > > > > > ownership of this task - all base build scripts need to be
> corrected for
> > > > > > arch,flags,etc
> > > > > > 3 - once the base is built, each developer is given a source tr=
ee
> > > > > > or trees and they work on those on top of the base(vlbase.tgz).=
eg.
> > > > > > kde,xap,etc - all packages must be built on a virgin base excep=
t
> for soho -
> > > > > > 2 groups are needed here - std and soho and there will be some
> duplication
> > > > > > as std and soho should be treated as separate distros - all bui=
ld
> scripts
> > > > > > need to corrected for arch,flags,etc
> > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > include that aren't in slack and split this up depending on how
> many pkgs
> > > > > > there are
> > > > > > 5 - upload all the built packages to the respective trees and e=
ach
> > > > > > of us install them for testing.
> > > > > > 6 - once testing is completed, we package these up for the cd i=
nto
> > > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that SO=
HO
> > > > > > can be KDE only and have all packages built for it using kde as=
 a
> dep.
> > > > > > 7 - release beta std and soho at the same time
> > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > 9 - fix and release rc
> > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 unt=
il
> > > > > > stable.
> > > > > > 11 - release final std and soho at the same time.
> > > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > > primary responsibility will be security patching
> > > > > > 13 - start working on extra packages for the repo
> > > > > > 14 - once there is a large repo of apps available, start the ne=
xt
> > > > > > cycle at step 1
> > > > > >
> > > > > > Let me know what you all think.  Having this process more
> > > > > > organized and coordinated will allow us to work quicker and mor=
e
> efficiently
> > > > > > giving us more time to create the extra app repo that is needed=
 to
> take VL
> > > > > > to the next level. That way when Robert becomes rich from VL, h=
e
> will share
> > > > > > with all of us - lol.
> > > > > >
> > > > > > Regards,
> > > > > >  Tony
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>