Main idea ?

[gapan]

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.

[gapan]

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?

[thenktor]

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.

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.

[.:B:.]

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.

To me that sounds like a medadistribution?

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.

[gapan]

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.

This can be done anyway!

[gapan]

To me that sounds like a medadistribution?

Yes, probably. Is that a bad thing?

I suppose most of you people prefer zendo/zpm over (x)netpkg?

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).

[JRD]

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.

[thenktor]

Thenktor: how about a wiki page to put ideas on? Might keep it easier to manage.

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

[thenktor]

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.

Sounds good.

For about the main idea of the new distro - is it really named "alcoholix" ???

No Just needed a name as working title and since this forum is running on my alcohol wiki site...

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.

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.

I really like the ZENBUILD way of building packages. It's simple and readable. Packages are generated in a good and standard way.

Yes! I'm doing all my packages with buildpkg! We should have something like this. But buildpkg may need some improvements.

[gapan]

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.

If zpm could be used with multiple repos, it would be great to have it!

is it really named "alcoholix" ???

No!

We'll have to come up with a proper name at some point... Not that much important at the moment.

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.

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)

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.

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.

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.

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.

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.

No disagreement there.

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),

Yep.

ZUR is a really good idea and must be take into consideration (cloned, used, ...)

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.