Menu
▾
▴
vectorlinux-devel
|
From: Jose J. R. <jo...@gm...> - 2006-10-05 16:52:52
|
During the repo overhaul I was doing today I came up with some suggestions and questions about possible changes to the repo structure. I'd like to discuss them here: Suggestions: - symlink cleanold, makeinfo-slack, makeinfo-slapt from each category to centralize fixes. - rename testing/ to unstable/ (this should be for development (cvs, alpha, beta) versions of apps, libs, etc.) - create a new, possibly unstructured testing/ category, but only for temp storage of packages to be checked for correctness. - rename kdei/ to kdei18/ - unclassified/ should be holding place till decided whether to put in unstable or extras. - extras/unclassified/: temp holding place (try not to abuse this). - unstable/unclassified/: temp holding place (try not to abuse this). - packages/unclassified/: temp holding place (try not to abuse this). - move the iso directories outside the package repos, to a version-separated structure inside a top-level iso/ category. Questions: - rename packages to stable ??? - rename base/ to libs/ (because stable/ already means the package is in the iso and will be used in distro-upgrade, also base and base-apps would be misleading in extra/ and unstable/) ??? - rename base-apps/ to apps/ (same reason as above) ??? Regards, Joe1962 |
|
From: Jose J. R. <jo...@gm...> - 2006-10-05 18:01:01
|
On 10/5/06, Jose J. Rodriguez <jo...@gm...> wrote: > During the repo overhaul I was doing today I came up with some > suggestions and questions about possible changes to the repo > structure. I'd like to discuss them here: > > Questions: > > - rename base/ to libs/ Obviously, this should have been move, not rename, because libs/ already exists. Regards, Joe1962 |
|
From: John B <joh...@gm...> - 2006-10-05 22:36:49
|
Here are my $2.00 on the matter. On 10/5/06, Jose J. Rodriguez <jo...@gm...> wrote: > During the repo overhaul I was doing today I came up with some > suggestions and questions about possible changes to the repo > structure. I'd like to discuss them here: > > Suggestions: > > - symlink cleanold, makeinfo-slack, makeinfo-slapt from each category > to centralize fixes. This makes sense. I would suggest that the master scripts be kept in the /home/vectorlinux directory rather than in the repo proper. > - rename testing/ to unstable/ (this should be for development (cvs, > alpha, beta) versions of apps, libs, etc.) > - create a new, possibly unstructured testing/ category, but only for > temp storage of packages to be checked for correctness. Maybe just keep testing as is and add an unstable directory for cvs stuff, etc. > - rename kdei/ to kdei18/ No problem with that. > - unclassified/ should be holding place till decided whether to put in > unstable or extras. > - extras/unclassified/: temp holding place (try not to abuse this). > - unstable/unclassified/: temp holding place (try not to abuse this). > - packages/unclassified/: temp holding place (try not to abuse this). The only issue here is that the makeinfo-slapt and makeinfo-slack scripts traverse the directory tree from the packages level. If we're going to have an "unclassified" directory, I think it would be best to keep it at the same level as the "packages" directory. That way, those unclassified items aren't made available via slapt-get or gslapt until decisions are made. > - move the iso directories outside the package repos, to a > version-separated structure inside a top-level iso/ category. > I have mixed thoughts on this one, so I'll pass for now. > > Questions: > > - rename packages to stable ??? This might not matter too much. > - rename base/ to libs/ (because stable/ already means the package is > in the iso and will be used in distro-upgrade, also base and base-apps > would be misleading in extra/ and unstable/) ??? > - rename base-apps/ to apps/ (same reason as above) ??? The major problem with making those two changes is that I have patched slapt-get for VL Dynamite so that the dist-upgrade mechanism will work. I've used base$ as the regex for slapt-get's searches. (For the slack repos, a$ is the search regex, which would search both the a and ap directories.) Also see the following from the slapt-get FAQ located at http://software.jaos.org/BUILD/slapt-get/FAQ.html#slgFAQ9 - 9. Can I "dist-upgrade" to a newer Slackware release? Yes. See also http://slackwiki.org/Upgrade_Using_Slapt-get. Change your source location within /etc/slapt-get/slapt-getrc to point to the newer release directory. --update your local package cache, then --dist-upgrade to the newer release. You will also want to disable any third party package sources while upgrading to a newer release due to the fact that third party packages might not be as rigorously tested as official packages, or may cause conflicts with files provided by official packages. For instance, you have the following line as your source: SOURCE=ftp://distro.ibiblio.org/pub/Linux/distributions/slackware/slackware-9.0/ Simply change the URL to point to current, like so: SOURCE=ftp://distro.ibiblio.org/pub/Linux/distributions/slackware/slackware-current/ CAVEAT: Follow the instructions in UPGRADE.TXT. Now you --dist-upgrade to retrieve the package data for that release. What dist-upgrade does is basically make sure that any missing packages from the base disk set are installed, as well as upgrade to any newer versions of the currently installed packages. All of this happens in one transaction. dist-upgrade'ing involves doing the following: ### upgrade your local package cache $ slapt-get --update ### first, download all of the packages prior to upgrading $ slapt-get --dist-upgrade --download-only ### second, install (not upgrade!) the newest kernel $ slapt-get --install kernel --no-upgrade ### then, upgrade the most important #(this installs any newer versions) $ slapt-get --install glibc-solibs pkgtools sed In newer versions of slapt-get, dist-upgrade automatically handles installing/upgrading glibc-solibs, pkgtools, and sed prior to any other changes. ### finally, let slapt-get upgrade the rest $ slapt-get --dist-upgrade You can specify --remove-obsolete to remove all depreciated packages. CAUTION: this can only take into consideration packages that are available from your current sources. Thus self made packages will be considered obsolete as well (they can be excluded within slapt-getrc, however). Only use this if you have been using Slackware packages exclusively. You can also use this option for information purposes, observing the obsolete packages, then passing all the ones you are sure of to --remove (which can accept multiple packages at once). ### dist upgrade and remove all depreciated/obsolete packages $ slapt-get --dist-upgrade --remove-obsolete Then follow the rest of the directions in UPGRADE.TXT. You should make sure any new packages within the disk sets you are using are also installed, as they will not be detected during --dist-upgrade, as only packages already installed will be upgraded. To accomplish this, you can specify slapt-get to install a disk set like so: ### install all X and X application packages $ slapt-get --install-set x xap Do the same for all your installed disk sets, such as gnome, x, xap, l, n, etc. As Jason explained to me, slapt-get needs to parse the a and ap directories for Slackware (analogous to our base and base-apps directories) so that the packages that are the real base of the distro are upgraded correctly. Of course this also means we would need to have all of the packages that are used on the ISO in the repository. > > Regards, > Joe1962 Again, just my $2.00, JohnB |
|
From: Jose J. R. <jo...@gm...> - 2006-10-05 23:09:54
|
On 10/5/06, John B <joh...@gm...> wrote: > Here are my $2.00 on the matter. > > On 10/5/06, Jose J. Rodriguez <jo...@gm...> wrote: > > During the repo overhaul I was doing today I came up with some > > suggestions and questions about possible changes to the repo > > structure. I'd like to discuss them here: > > > > - rename testing/ to unstable/ (this should be for development (cvs, > > alpha, beta) versions of apps, libs, etc.) > > - create a new, possibly unstructured testing/ category, but only for > > temp storage of packages to be checked for correctness. > > Maybe just keep testing as is and add an unstable directory for cvs stuff, etc. > Could be too, but sounds more logical the other way around, IMHO. > > > - unclassified/ should be holding place till decided whether to put in > > unstable or extras. > > - extras/unclassified/: temp holding place (try not to abuse this). > > - unstable/unclassified/: temp holding place (try not to abuse this). > > - packages/unclassified/: temp holding place (try not to abuse this). > > The only issue here is that the makeinfo-slapt and makeinfo-slack > scripts traverse the directory tree from the packages level. If we're > going to have an "unclassified" directory, I think it would be best to > keep it at the same level as the "packages" directory. That way, those > unclassified items aren't made available via slapt-get or gslapt until > decisions are made. > Agreed, I was leaning in this direction myself. > > > - rename packages to stable ??? > > This might not matter too much. > Maybe release or a similar name is better, see comment below regarding dist-upgrade for more on this. > > > - rename base/ to libs/ (because stable/ already means the package is > > in the iso and will be used in distro-upgrade, also base and base-apps > > would be misleading in extra/ and unstable/) ??? > > - rename base-apps/ to apps/ (same reason as above) ??? > > The major problem with making those two changes is that I have patched > slapt-get for VL Dynamite so that the dist-upgrade mechanism will > work. I've used base$ as the regex for slapt-get's searches. (For the > slack repos, a$ is the search regex, which would search both the a and > ap directories.) > <snip> > > As Jason explained to me, slapt-get needs to parse the a and ap > directories for Slackware (analogous to our base and base-apps > directories) so that the packages that are the real base of the distro > are upgraded correctly. Of course this also means we would need to > have all of the packages that are used on the ISO in the repository. > As I understood it in earlier discussions, the packages repo (or stable, or whatever) was only for those apps included in the distro and that would be subject to a distro-upgrade. Everything else would be in extras. So maybe a name like "release" (or any other that helps to bring that idea across) would be more understandable. Anyway, if a and ap (base and base-apps) are not analogous to the cli libs and apps released with the iso, then I understand your point. We also need to decide if this repo category will include just the packages that make up the "bulks", or also the optionally selectable packages that are listed later on during install. Regards, Joe1962 |
|
From: Kocil <k0...@ya...> - 2006-10-08 09:10:45
|
Hi admin. I have problem logging in into the new forum. It always says "Your email address needs to be validated before you can login. Need another activation email?" But when I asked another activation email, it says "Error, your account has been activated". Please help. Kocil. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: John B <joh...@gm...> - 2006-10-08 13:19:09
|
Kocil, You were on the list of members waiting to be activated. I've activated your account. Before you go into the VL forum, clear your browser's cache and clear out any cookies related to the VL forum just to be on the safe side. ;-) Thanks, John On 10/8/06, Kocil <k0...@ya...> wrote: > Hi admin. > > I have problem logging in into the new forum. > It always says > "Your email address needs to be validated before you > can login. Need another activation email?" > > But when I asked another activation email, it says > "Error, your account has been activated". > > Please help. > Kocil. > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vectorlinux-devel mailing list > Vec...@li... > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel > |
×
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