Re: [Vectorlinux-devel] "Unstable" repository

[Jose J. R. <jo...@gm...>]

On 4/25/06, John B <joh...@gm...> wrote:
> We do need a pasture directory. Since I'll be doing primary work on
> maintaining the repo, I want to have a place to move the old stuff so
> that it doesn't show up in slapt-get/gslapt, espcially when we've
> updated core packages due to security fixes, etc. We have to avoid
> duplicate versions and/or duplicate packages.
>
> I can also argue for an unsupported directory, in that it's a place
> where we put software that is no longer being supported by its author,
> etc.
>

Yes, now I can see your point.

> While we're talking about packaging standards, we absolutely need to
> use dependencies that are part of the core unless there is a
> compelling reason to use a different version. I speak mainly of gtk,
> though this would also apply to qt, wxwidgets, etc. I don't want to
> see us have multiple versions of gtk2 or qt in the main package tree.
>

I agree with this, though I've been one of the culprits, specially at
the beginning of my packaging days. See my first Gimp (2.2.10) to see
what I mean. However, wxwidgets is a tough case, as many apps "choose"
to work with a certain specific version.

> One additional comment on the "current" directory - we should take the
> same position that Patrick V takes with the slackware-current tree.
> Besides Joe's comment about updated versions of apps and libs being in
> there (i.e., feature enhancements), it should also be seen as the
> place where development work on future versions of VL takes place.
> Therefore, while the stuff in there should work, we should make a
> strong disclaimer that anything in veclinux-current may break your
> box. I envision "current" as a directory that would eventually become
> frozen to a specific release.
>

I can understand this wish, but this means packages for the next
release get built based on the same versions of the base libs, etc. So
if I understand right, this is for point releases only, not for a full
version change (ie. from 6.x to 7.0) which would be based on newer
technology? Or how does Slackware handle such cases?

Regards,
Joe1962