So what should the main idea behind the "Alcoholix" project be?
We probably want to keep everything we liked about Zenwalk. After all we all went to Zenwalk for a reason.
At the same time we should dump everything we didn't like...
An idea that I had and talked about with a couple of people was to keep it as close to slackware as possible. Basically synchronize 100% with slackware releases and be 100% backwards compatible with it, essentially providing a "plug-in" distribution for slackware. That way we contribute back to slackware and all slackware users can install any package from our repos. That will also probably mean that our first release will be 13.0.
Main idea ?
Re: Main idea ?
And... provide a full featured slackware installation (with probably a gtk+2 environment) that could fit in a single CD (the smaller, the better). Sounds a lot like minislack, doesn't it?
Re: Main idea ?
But I really would want to replace some Slackware packages with own packages, so a plug-in only system is not enough in my opinion.gapan wrote:An idea that I had and talked about with a couple of people was to keep it as close to slackware as possible. Basically synchronize 100% with slackware releases and be 100% backwards compatible with it, essentially providing a "plug-in" distribution for slackware. That way we contribute back to slackware and all slackware users can install any package from our repos. That will also probably mean that our first release will be 13.0.
Re: Main idea ?
To me that sounds like a medadistribution?gapan wrote:So what should the main idea behind the "Alcoholix" project be?
We probably want to keep everything we liked about Zenwalk. After all we all went to Zenwalk for a reason.
At the same time we should dump everything we didn't like...
An idea that I had and talked about with a couple of people was to keep it as close to slackware as possible. Basically synchronize 100% with slackware releases and be 100% backwards compatible with it, essentially providing a "plug-in" distribution for slackware. That way we contribute back to slackware and all slackware users can install any package from our repos. That will also probably mean that our first release will be 13.0.
I suppose most of you people prefer zendo/zpm over (x)netpkg?
Thenktor: how about a wiki page to put ideas on? Might keep it easier to manage.
Re: Main idea ?
This can be done anyway!thenktor wrote:But I really would want to replace some Slackware packages with own packages, so a plug-in only system is not enough in my opinion.
Re: Main idea ?
Yes, probably. Is that a bad thing?.:B:. wrote:To me that sounds like a medadistribution?
I do. But I'm thinking about slapt-get/gslapt, because it supports multiple repos. That way we won't need to pull slackware packages and put them in our repos (downside: no dependency support for slack packages, maybe we can work around it somehow)..:B:. wrote:I suppose most of you people prefer zendo/zpm over (x)netpkg?
Re: Main idea ?
zpm is in active developpement and Sparky would want to make it handle others distro than Zenwalk/Slackware.
He told me he wanted to handle many repos and others thinks like that.
For about the main idea of the new distro - is it really named "alcoholix" ??? - I'm in the oppposite direction of Gapan. I see a distro which is based on Slackware/Zenwalk but that do not try to be compatible. One of the thinks that I dislike in Zenwalk is that the distro does not go forward and is not innovative because of the willing to be compatible with Slackware. We rely on Slackware way of release and advancement.
If one software (A) is updated in slackware and we take another one (B) that depends on it, we must update A in the same time, and all others packages that depend on A. Other scenarios like this had made huge headaches on Zenwalk... If we TAKE slackware (or Zenwalk) packages, but afterwards, it's ours, we could better manage the versions tree. It will be painless.
For me the harder work is when doing a package for the first time, and when a software change a significant vertsion (like KDE or the like). Most of the time, a simple recompile with the new software versions is enough.
I really like the ZENBUILD way of building packages. It's simple and readable. Packages are generated in a good and standard way.
I also like the KISS in Zenwalk, and the One Application Per Task. It's not because Zenwalk is now quite non-innovative, than we mustn't take the good of it Let's make a Zenwalk++ distro But I think here, everybody's agree
What is important for me is that the distro must have a kernel of people who takes big decisions, and not just one man/woman. A pseudo-democratical way of leading is better than one person.
The way of submit new/updated packages must also be more trackable than in Zenwalk, a real test team must be set (eventually one for each category), ZUR is a really good idea and must be take into consideration (cloned, used, ...)
That's a bit of thinks that come out of my mind for now.
He told me he wanted to handle many repos and others thinks like that.
For about the main idea of the new distro - is it really named "alcoholix" ??? - I'm in the oppposite direction of Gapan. I see a distro which is based on Slackware/Zenwalk but that do not try to be compatible. One of the thinks that I dislike in Zenwalk is that the distro does not go forward and is not innovative because of the willing to be compatible with Slackware. We rely on Slackware way of release and advancement.
If one software (A) is updated in slackware and we take another one (B) that depends on it, we must update A in the same time, and all others packages that depend on A. Other scenarios like this had made huge headaches on Zenwalk... If we TAKE slackware (or Zenwalk) packages, but afterwards, it's ours, we could better manage the versions tree. It will be painless.
For me the harder work is when doing a package for the first time, and when a software change a significant vertsion (like KDE or the like). Most of the time, a simple recompile with the new software versions is enough.
I really like the ZENBUILD way of building packages. It's simple and readable. Packages are generated in a good and standard way.
I also like the KISS in Zenwalk, and the One Application Per Task. It's not because Zenwalk is now quite non-innovative, than we mustn't take the good of it Let's make a Zenwalk++ distro But I think here, everybody's agree
What is important for me is that the distro must have a kernel of people who takes big decisions, and not just one man/woman. A pseudo-democratical way of leading is better than one person.
The way of submit new/updated packages must also be more trackable than in Zenwalk, a real test team must be set (eventually one for each category), ZUR is a really good idea and must be take into consideration (cloned, used, ...)
That's a bit of thinks that come out of my mind for now.
Re: Main idea ?
Perhaps we can use something like this: http://www.wikidot.com/ I don't want to set up another wiki on my site because it's already running one.:B:. wrote:Thenktor: how about a wiki page to put ideas on? Might keep it easier to manage.
Re: Main idea ?
Sounds good.JRD wrote:zpm is in active developpement and Sparky would want to make it handle others distro than Zenwalk/Slackware.
He told me he wanted to handle many repos and others thinks like that.
No Just needed a name as working title and since this forum is running on my alcohol wiki site...JRD wrote:For about the main idea of the new distro - is it really named "alcoholix" ???
I know what you mean. There are some issues in Slackware that probably never will get fixed (e.g. an uninst.sh in pkgtools) In my opinion we should take as much of Slackware as we can, but if we need to break compatibility for innovative features we should not hestitate to do so.JRD wrote:I'm in the oppposite direction of Gapan. I see a distro which is based on Slackware/Zenwalk but that do not try to be compatible. One of the thinks that I dislike in Zenwalk is that the distro does not go forward and is not innovative because of the willing to be compatible with Slackware. We rely on Slackware way of release and advancement.
Yes! I'm doing all my packages with buildpkg! We should have something like this. But buildpkg may need some improvements.JRD wrote:I really like the ZENBUILD way of building packages. It's simple and readable. Packages are generated in a good and standard way.
Re: Main idea ?
If zpm could be used with multiple repos, it would be great to have it!JRD wrote:zpm is in active developpement and Sparky would want to make it handle others distro than Zenwalk/Slackware.
He told me he wanted to handle many repos and others thinks like that.
No!JRD wrote:is it really named "alcoholix" ???
We'll have to come up with a proper name at some point... Not that much important at the moment.
I don't understand your concerns... We have to base in on something, we can't make something from the ground up (no manpower) and slackware is the simplest and best choice I think. We can innovative in other ways (installation, localization etc)JRD wrote:I'm in the oppposite direction of Gapan. I see a distro which is based on Slackware/Zenwalk but that do not try to be compatible. One of the thinks that I dislike in Zenwalk is that the distro does not go forward and is not innovative because of the willing to be compatible with Slackware. We rely on Slackware way of release and advancement.
Maybe it isn't clear what I'm thinking: use slackware repos directly, don't put slackware packages in our repos. Such package updates that you're describing only occur in slackware current (the development branch), the stable version will never suffer from this.JRD wrote:If one software (A) is updated in slackware and we take another one (B) that depends on it, we must update A in the same time, and all others packages that depend on A.
But it requires more effort to maintain our own versions of everything. I don't think we can do that. I think we need to keep our workload to minimum possible.JRD wrote:Other scenarios like this had made huge headaches on Zenwalk... If we TAKE slackware (or Zenwalk) packages, but afterwards, it's ours, we could better manage the versions tree. It will be painless.
No disagreement there.JRD wrote:I really like the ZENBUILD way of building packages. It's simple and readable. Packages are generated in a good and standard way.
I also like the KISS in Zenwalk, and the One Application Per Task.
Yep.JRD wrote:What is important for me is that the distro must have a kernel of people who takes big decisions, and not just one man/woman. A pseudo-democratical way of leading is better than one person.
The way of submit new/updated packages must also be more trackable than in Zenwalk, a real test team must be set (eventually one for each category),
Hmmm... I don't think I like ZUR that much... I prefer to have packages tested and put in "official" repos than having them uploaded without any testing. Arch's AUR is good but it's a completely different thing. Anyway, I don't think we should worry about the community just yet, just focus on basic stuff.JRD wrote:ZUR is a really good idea and must be take into consideration (cloned, used, ...)