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

[uel a. <ue...@gm...>]

Tony,
The package lists are fially finished
they are in vectors folder on the ftp
let us know if you need anything else.

Thanks,
Uel

On 4/13/06, Tony Brijeski <tb...@gm...> wrote:
>
> I'm still waiting for everyone to decide on a package list - complete.
> Once we have that, I will build the base.
>
>
>
>
> On 4/14/06, uel archuletta < ue...@gm...> wrote:
> >
> > Tony,
> > How is everything going with the "Base" so far?
> > just thought I would check in and get an update.
> >
> > Thanks,
> > Uel
> >
> > On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> >
> > >  I agree that std and soho should be separate and should have separat=
e
> > 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
> > suggest
> > > 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..
> > changes
> > > 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 a=
s
> > their
> > > 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 soh=
o
> > . 2.
> > > is possible
> > >
> > > And it makes development and package management a lot easier if we
> > consider
> > > them two seperate Distros altogether.. they share only the vector
> > > philosophy.. and the non KDE part of the initial base system.  All
> > packages
> > > 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
> > users
> > > :)
> > > 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
> > this
> > > > > > > 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 std
> > > so it
> > > > > > is possible.
> > > > > >
> > > > >
> > > > > That is workable 2 seperate workloads if one has time/space they
> > could
> > > > > 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 we
> > > > > 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 buil=
d
> > 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 hav=
e
> > > > kde-centric additions wherever possible to integrate them better
> > into the
> > > > desktop environment. While we may use the same apps for std, they
> > should
> > > not
> > > > have kde deps in them.  This is kind of like the issue you get if
> > you try
> > > 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.  Soho
> > > > 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
> > includes
> > > > > > 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 mea=
n
> > > adding it
> > > > > to the metapackage
> > > > >
> > > > >
> > > >
> > > >
> > > > I really don't think xfce should be in SOHO.  IMHO, 99% of those
> > that get
> > > > SOHO are getting it for kde and not xfce.  If they want xfce, they
> > should
> > > > stick with std.  This would also allow us to make soho easier and
> > better
> > > due
> > > > to the fact that you wouldn't have to worry about menus and such as
> > long
> > > 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 lookin=
g
> > for
> > > > xfce.  Again, we need to go back and look at the target market for
> > these
> > > and
> > > > not what we want out of it.  We could always add wm's and such to
> > the repo
> > > > but I doubt they'd get a lot of hits.
> > > >
> > > > Concentrating only on kde for soho would be the best bet.  choosing
> > apps
> > > > for soho should also be centred around kde as well so they integrat=
e
> > > > properly into the DE.  The maturity of the apps for kde is there no=
w
> > and
> > > 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 to
> > > > 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
> > have
> > > > > > > > as well.
> > > > > > > >
> > > > > > > > I think we can work with these to build our base from sourc=
e
> > and
> > > > > > > > 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 tha=
t
> > wants
> > > 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 sourc=
e
> > tree
> > > > > > > > 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
> > except
> > > 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
> > build
> > > 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 each
> > > > > > > > of us install them for testing.
> > > > > > > > 6 - once testing is completed, we package these up for the
> > cd into
> > > > > > > > vl-base.tgz,vl-std.tgz , and vl-soho.tgz - all X and relate=
d
> > > > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so tha=
t
> > SOHO
> > > > > > > > can be KDE only and have all packages built for it using kd=
e
> > 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
> > until
> > > > > > > > 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 th=
e
> > next
> > > > > > > > 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
> > more
> > > 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, he
> > > will share
> > > > > > > > with all of us - lol.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >  Tony
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > -------------------------------------------------------
> >
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the live
> > webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642<h=
ttp://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642>
> > _______________________________________________
> > Vectorlinux-devel mailing list
> > Vec...@li...
> > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> >
> >
>