Menu
▾
▴
vectorlinux-devel
|
From: Jose J. R. <jo...@gm...> - 2006-03-02 19:56:20
|
Were not all here yet (we've got around 66% of the proposed members in), but sort of to break the ice, here goes my first post to the list. And it's sort of the reason behind the list idea, since johnvan was already gone for the night and I didn't want to forget about this matter, lol. I think a non-realtime discussion vehicle like this is also very useful and doesn't require you to be online at the Forum either. As I was packaging Amarok 1.4 beta1 last night, I was wondering if I should upload it for general consumption, because it's a beta app and people tend to upgrade everything lately, something that has caused problems already. So I figured we need an "unstable" repository. We have "testing", but that's for testing packages with regard to packaging problems. All packages should start in testing, but then get moved to "stable" or "unstable" according to the status of the app itself. Regards, Joe1962 |
|
From: Tony B. <tb...@gm...> - 2006-03-02 20:13:03
|
Stable should be reserved for all packages that are either the same version or a bugfix or securyt fix version of the original app included in the distribution. An upgrade to something like KDE 3.5.x should be considered "current" and not necessarily unstable. This is where development on the next version should take place like slackware and so many other distros do. This would also provide an upgrade path for previous versions and solve that issue as well as a lot of folks always want to upgrade their system without having t= o reinstall the os. Clearly any app that is in true beta form should be in "unstable" and shoul= d remain there until it is not beta anymore. There are a lot of beta apps that are really stable and shouldn't be deemed beta anyway. Latest and greatest apps should go here and when they pass the muster, they should be moved to current. I believe there should also be an "extra" repo where addon apps are put after the final version of the distro has been released. Lets say someone wants avidemux or dydstyler, they should go here and not stable as the distro never had it to begin with and for the most part it is untested on a large enough scale. This would also put less pressure on the maintainers o= f the extra repo apps. This way the people that want a rock solid distro without having to get new packages or go bleeding edge, could be assured that the stable repo will only have bugfixes or security fixes for the main distro. I don't see a point in having a bugfix or security repo as those can just b= e seemlessly roled back into the stable repo. The stable repo would be the most important, followed by the extra repo and then the current repo. Regards, Tony aka Spider On 3/2/06, Jose J. Rodriguez <jo...@gm...> wrote: > > Were not all here yet (we've got around 66% of the proposed members > in), but sort of to break the ice, here goes my first post to the > list. And it's sort of the reason behind the list idea, since johnvan > was already gone for the night and I didn't want to forget about this > matter, lol. I think a non-realtime discussion vehicle like this is > also very useful and doesn't require you to be online at the Forum > either. > > As I was packaging Amarok 1.4 beta1 last night, I was wondering if I > should upload it for general consumption, because it's a beta app and > people tend to upgrade everything lately, something that has caused > problems already. So I figured we need an "unstable" repository. We > have "testing", but that's for testing packages with regard to > packaging problems. All packages should start in testing, but then get > moved to "stable" or "unstable" according to the status of the app > itself. > > Regards, > Joe1962 > > > ------------------------------------------------------- > 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 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
|
From: John B <joh...@gm...> - 2006-03-02 23:29:59
|
To add to Tony's comments, we should also add pasture and unsupported subdirectories in the main repository. They would serve the same purpose that they do in Slackware - pasture would be used for holding old packages, and unsupported would be the holding place for packages we no longer suppor= t but should be kept around for historical interest. While we're talking about the repository, I think we should enable the ability to use the slapt-get --dist-upgrade flag to enable upgrade to a new version without having to download and install an ISO. If we do this, however, it would mean that we would have to have EVERY package that would come on an ISO in our repository, especially for the benefit of the VL user= s who don't want to enable the official slackware repos. Let's hash this out some on the list. If Jason Woodward, aka jaos, has been invited to this mailing list, I'm sure he'll add some insight on this. Regards, John |
|
From: Tony B. <tb...@gm...> - 2006-03-03 01:55:10
|
I started work on a repackaging tool just before I left. It took the entries from /var/log/packages and /var/log/scripts and repackaged them as = a tgz package. IMHO, this would be the best way to create individual package= s after tweaking and then also create some custom vl packages to encompass /etc/skel and /root. we really need to start creating new folders for each version. We are usin= g 5.0 on the repo and the version of the distro is 5.1. This is confusing an= d needs to be addressed before the next version. On 3/2/06, John B <joh...@gm...> wrote: > > To add to Tony's comments, we should also add pasture and unsupported > subdirectories in the main repository. They would serve the same purpose > that they do in Slackware - pasture would be used for holding old package= s, > and unsupported would be the holding place for packages we no longer supp= ort > but should be kept around for historical interest. > > While we're talking about the repository, I think we should enable the > ability to use the slapt-get --dist-upgrade flag to enable upgrade to a n= ew > version without having to download and install an ISO. If we do this, > however, it would mean that we would have to have EVERY package that woul= d > come on an ISO in our repository, especially for the benefit of the VL us= ers > who don't want to enable the official slackware repos. Let's hash this ou= t > some on the list. If Jason Woodward, aka jaos, has been invited to this > mailing list, I'm sure he'll add some insight on this. > > Regards, > John > |
|
From: Jose J. R. <jo...@gm...> - 2006-03-03 03:58:36
|
On 3/2/06, Tony Brijeski <tb...@gm...> wrote: > we really need to start creating new folders for each version. We are us= ing > 5.0 on the repo and the version of the distro is 5.1. This is confusing = and > needs to be addressed before the next version. It's not just the version number. SOHO 5.1 packages won't install (unless forced) on Standard 5.1 due to dependencies. In recent talks we seem to have agreed that the way to go for 6.0 is to get a common base going (similar to the Dynamite concept, before it became a distro, lol). Standard and SOHO would build on this base in parallel. If this base is used to build the common packages, this problem goes away. We need to think carefully of packages that require more than the base deps though. > On 3/2/06, John B <joh...@gm...> wrote: > > > > To add to Tony's comments, we should also add pasture and unsupported > subdirectories in the main repository. They would serve the same purpose > that they do in Slackware - pasture would be used for holding old package= s, > and unsupported would be the holding place for packages we no longer supp= ort > but should be kept around for historical interest. Isn't that a very fine line between those 2? Or am I missing something here? (prolly am, lol). Regards, Joe1962 |
|
From: Jose J. R. <jo...@gm...> - 2006-03-03 04:04:18
|
On 3/2/06, John B <joh...@gm...> wrote: > If Jason Woodward, aka jaos, has been invited to this > mailing list, I'm sure he'll add some insight on this. He's subscribed. Regards, Joe1962 |
|
From: Jose J. R. <jo...@gm...> - 2006-04-25 06:33:46
|
I'd like to awaken this thread because we need to come to a decision regarding the structure of the VL6 repo. VL6 will be breaking new ground for us in the packaging department, as all packages that make up the distro will be available on the repo, to allow for rolling back upgrades, etc. Also, we intend to make dist-upgrade possible, as discussed before. So we need to get the repo structure just right. Also, we need to think about separating the repos for Standard and SOHO, or (probably impossible) making the packages installable for both. Looking at previous posts, I'd like to sum up a possible repo structure and ask for comments/discussions. -testing: every package should go here till deemed worthy by a team of official package testers, then sent to it's rightful place. -stable: (or official): for bug fixes or security updates of the libs / apps included on the distro. -extra: (or unofficial): for libs / apps not included in the distro. -current: for updated versions of libs / apps included in the distro, but not simple security /bug fixes, rather feature updates. -unstable: for beta and rc apps, whether included in the distro or not. -pasture and unsupported have been proposed, but so far I don't see the use for them within the timeline of a VL version, your views on this? Regards, Joe1962 |
|
From: uel a. <ue...@gm...> - 2006-04-25 06:54:24
|
I agree with everything, But I read it a little diferently so I would propose these changes -testing: every package should go here till deemed worthy by a team of official package testers, then sent to it's rightful place. -stable: (or official): only for the specific versions of apps/libs in the release or their security/bug fixes -extra: (or unofficial): for libs / apps not included in the distro. -current: for updated versions of libs / apps included in the distro, but not simple security /bug fixes, rather feature updates. -unstable: for beta and rc apps. I would also volunteer for testing packages as I have room to keep a clean box to install them onto. Thanks Uel On 4/25/06, Jose J. Rodriguez <jo...@gm...> wrote: > > I'd like to awaken this thread because we need to come to a decision > regarding the structure of the VL6 repo. VL6 will be breaking new > ground for us in the packaging department, as all packages that make > up the distro will be available on the repo, to allow for rolling back > upgrades, etc. Also, we intend to make dist-upgrade possible, as > discussed before. So we need to get the repo structure just right. > Also, we need to think about separating the repos for Standard and > SOHO, or (probably impossible) making the packages installable for > both. Looking at previous posts, I'd like to sum up a possible repo > structure and ask for comments/discussions. > > -testing: every package should go here till deemed worthy by a team of > official package testers, then sent to it's rightful place. > > -stable: (or official): for bug fixes or security updates of the libs > / apps included on the distro. > > -extra: (or unofficial): for libs / apps not included in the distro. > > -current: for updated versions of libs / apps included in the distro, > but not simple security /bug fixes, rather feature updates. > > -unstable: for beta and rc apps, whether included in the distro or not. > > -pasture and unsupported have been proposed, but so far I don't see > the use for them within the timeline of a VL version, your views on > this? > > Regards, > Joe1962 > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
|
From: John B <joh...@gm...> - 2006-04-25 16:16:29
|
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. 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. 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. FWIW, John On 4/25/06, uel archuletta <ue...@gm...> wrote: > I agree with everything, But I read it a little diferently so I would > propose these changes > > > -testing: every package should go here till deemed worthy by a team of > official package testers, then sent to it's rightful place. > > -stable: (or official): only for the specific versions of apps/libs in th= e > release or their security/bug fixes > > > -extra: (or unofficial): for libs / apps not included in the distro. > > -current: for updated versions of libs / apps included in the distro, > but not simple security /bug fixes, rather feature updates. > > -unstable: for beta and rc apps. > > I would also volunteer for testing packages as I have room to keep a clea= n > box to install them onto. > > Thanks > Uel > > > > > On 4/25/06, Jose J. Rodriguez <jo...@gm...> wrote: > > I'd like to awaken this thread because we need to come to a decision > > regarding the structure of the VL6 repo. VL6 will be breaking new > > ground for us in the packaging department, as all packages that make > > up the distro will be available on the repo, to allow for rolling back > > upgrades, etc. Also, we intend to make dist-upgrade possible, as > > discussed before. So we need to get the repo structure just right. > > Also, we need to think about separating the repos for Standard and > > SOHO, or (probably impossible) making the packages installable for > > both. Looking at previous posts, I'd like to sum up a possible repo > > structure and ask for comments/discussions. > > > > -testing: every package should go here till deemed worthy by a team of > > official package testers, then sent to it's rightful place. > > > > -stable: (or official): for bug fixes or security updates of the libs > > / apps included on the distro. > > > > -extra: (or unofficial): for libs / apps not included in the distro. > > > > -current: for updated versions of libs / apps included in the distro, > > but not simple security /bug fixes, rather feature updates. > > > > -unstable: for beta and rc apps, whether included in the distro or not. > > > > -pasture and unsupported have been proposed, but so far I don't see > > the use for them within the timeline of a VL version, your views on > > this? > > > > Regards, > > Joe1962 > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, securit= y? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > > _______________________________________________ > > Vectorlinux-devel mailing list > > Vec...@li... > > > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > > > > |
|
From: Jose J. R. <jo...@gm...> - 2006-04-26 00:35:48
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X