VectorLinux
September 22, 2014, 04:01:38 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: 1 [2]
  Print  
Author Topic: Discussion of "Patches" repository guidelines  (Read 9720 times)
The Headacher
Louder than you
Global Moderator
Vectorian
*****
Posts: 1548


I like the bass to go BOOM!


WWW
« Reply #15 on: June 26, 2007, 01:55:27 am »

Quote from: Caitlyn
1- Is doing a major upgrade of core libraries with a release cycle (i.e.: gtk+2, glib2) was a good idea or not?
I'd rather stay with the latest stable Slack versions of those libraries if possible, or Slack current if we really have to upgrade.

Quote
2-  Should such upgrades should go into patches so that anyone who does a slapt-get --upgrade gets them or rather should they be in a separate repository with patches reserved for security patches and bugfixes and
Well, at least they shouldn't go into patches, that much seems obvious to me now.

Quote
3-  Since so many manjor upgrades to 5.8 have been offered should VL respin the Standard ISO and call it VL 5.8.1. or something, including all the patches to date since they are tested
I'm not sure what would be the benefit of this. If we wait a few weeks/months we can start playing with slack 12 and apply what we have learned with VL 5.8 on VL 6.

Quote from: Uelsk8s
2. these packages should have been put into the Gnome folder in the 5.8 repo, and that is where I understood they were going to be put.
Let's please watch out for creating a lot of different repo's, that's very Debianesque and juist plain confusing (Last time I tried some Debian based distro I even needed to add some weird repo for the Nvidia driver, the binary didn't compile on it).. I mean, just for Gnome is fine of course, we'd better watch out for fragmenting the repo's too much though.
Logged

Most music on my soundcloud page was arranged in programs running on VL.
Darin
Member
*
Posts: 35



« Reply #16 on: June 26, 2007, 05:21:45 am »

why not have 2 branches...one is testing and the other is normal....now you can move the testing-updates over to normal pretty easily...as for the foundation of the branch...why not use the same as a the package was made for..lets come up with a revised skeleton for kde...or even use the repo branch to be the same...makes where to put packages alot easier as you can have gnome or any other window manager in a window manager section....simplicity is the answer especially with people contributing packages..just my 2 cents on how to clear some confusion in things
Logged
Joe1962
Administrator
Vectorian
*****
Posts: 2499



WWW
« Reply #17 on: June 26, 2007, 10:07:32 am »

I agree too many repos is complicated, but too few is a problem, so I guess we need to find a balance. Maybe we need to set up an "experimental" repo for stuff like that gtk upgrade? Then we can keep "patches" for bug or security fixes and "extra" for non-iso packages built on the vanilla release (or built on the patches at most).
Logged

O'Neill (RE the Asgard): "Usually they ask nicely before they ignore us and do what they damn well please."
http://joe1962.bigbox.info
Running: VL 7 Std 64 + self-cooked XFCE-4.10
caitlyn
Packager
Vectorian
****
Posts: 2876


WWW
« Reply #18 on: June 26, 2007, 12:36:14 pm »

I like Joe1962's suggestion.  It seems like a good, balanced approach to the repos for future interesting upgrades that we might not want to be universal.

The advantages of a respin are two fold:

1.  For packagers and developers it gives us a new base from which to build.  Right now if I build on a "clean machine:" per VL standards and build against gtk+2 2.8.x there is no guarantee my package will work on a machine where patches have been applied.  If I build against gtk+2 2.10.11 my package will force an upgrade if installed with gslapt or slapt-get and may not work on a machine where patches have been applied.  By spinning a new release gtk+2 2.10.11 as well as the upgraded versions of cairo, glib2, pango, atk, etc... all become the standard that everyone works from.

2.  For users they get a tested and fully upgraded, GNOME-ready VL Standard built on the same 2.6.20 kernel as SOHO.  It saves hundreds of megabytes (or possibly over a gig now if you include a kernel upgrade) or downloads of patches if you choose to keep your machine up to date for security and bugfixes.

If it meant a lot of work for the developers I'd agree with waiting for VL 6.  The point is that other than testing the installer with new package bundles everything has already been developed and thoroughly tested.  This would only be an incremental release, not a new development cycle.
Logged

eMachines EL-1300G desktop, 1.6GHz AMD Athlon 2650e CPU, 4GB RAM, nVidia GeForce 6150 SE video
CentOS 6.5 (will try VL64-7.1 soon)

Toshiba Satellite A135-S4727,  Intel Pentium T2080 / 1.73 GHz, 2GB RAM, Intel GMA 950

HP Mini 110 netbook, 1.6GHz Intel Atom CPU, 2GB RAM, Intel 950 video, VL 7.1
The Headacher
Louder than you
Global Moderator
Vectorian
*****
Posts: 1548


I like the bass to go BOOM!


WWW
« Reply #19 on: June 26, 2007, 02:00:02 pm »

Quote
For packagers and developers it gives us a new base from which to build.  Right now if I build on a "clean machine:" per VL standards and build against gtk+2 2.8.x there is no guarantee my package will work on a machine where patches have been applied.  If I build against gtk+2 2.10.11 my package will force an upgrade if installed with gslapt or slapt-get and may not work on a machine where patches have been applied.  By spinning a new release gtk+2 2.10.11 as well as the upgraded versions of cairo, glib2, pango, atk, etc... all become the standard that everyone works from.

And break Slack 11 compatibility... the gtk package that comes with vl 5.8 is the default one from Slack 11. So if gtk 2.2.8 packages don't work properly on 2.2.10 it would be a release for which linuxpackages.net and slacky.eu are no longer useful package resources (at least for apps that use gtk).

I for one don't care much for a new version of VL 5.8 just because some package went to the wrong repo and now we're stuck with some weird packages we're not sure what to do with. The differences between the 2 versions aren't that huge IMO. If we're going to release a new standard with updated gtk etc. we'll also need to release a new SOHO, or just accept the fact that packages on "5.8.1 standard" will not work on "5.8 SOHO" without massive forced upgrading of packages. Or package on 5.8 standard after all so it will work on both most of the times.

Everything I've built on a clean 5.8 standard install has worked just dandy on SOHO (at least for me) . I honestly don't see much of a point in starting completely over with very little packages in the repo. We'll have to do that when VL 6 is released, which is one of the reasons I'm trying to learn SlackBuilds ATM. 

How's about nuking the offending packages (or at least moving them somewhere that isn't a repo that's enabled by default) to start with?
Logged

Most music on my soundcloud page was arranged in programs running on VL.
easuter
Global Moderator
Vectorian
*****
Posts: 2160



« Reply #20 on: June 26, 2007, 02:28:23 pm »

Quote
And break Slack 11 compatibility... the gtk package that comes with vl 5.8 is the default one from Slack 11. So if gtk 2.2.8 packages don't work properly on 2.2.10 it would be a release for which linuxpackages.net and slacky.eu are no longer useful package resources (at least for apps that use gtk).

But the GTK upgrade doesn't break GTK 2.8-based packages, Xfce and the rest continue to work after the upgrade (except for wifi-radar).
Anyway, I wouldn't have uploaded the packages if they were "destructive", its one of the reasons it took me so long to get GTK and GNOME finished: test packages, fix problems, test again, fix other problems, test again, fix, fix, fix, test, test, test, and so forth untill it worked...  Lips sealed

But yes, I do agree with sticking to "major" Slackware packages for official releases of VL.

So we have a few options, based on the discussion in the thread (but not limited to):

-nuke the packages
-create an "updates" repo
-create a gnome repo, where everything that gnome relies on, upgrade-wise, must be moved to along with the gnome core packages
-create a new release of VL with these packages as a base

Now its really up to the VL elders to make a decision regarding this Wink
« Last Edit: June 26, 2007, 02:47:12 pm by easuter » Logged

Joe1962
Administrator
Vectorian
*****
Posts: 2499



WWW
« Reply #21 on: June 26, 2007, 03:27:01 pm »

If we go the new repo route, I'd rather it isn't called "upgrades" or anything like that, because it sounds confusingly similar to "patches". I would prefer "experimental", or something in that vein. Even "contrib" if necessary... Grin
Logged

O'Neill (RE the Asgard): "Usually they ask nicely before they ignore us and do what they damn well please."
http://joe1962.bigbox.info
Running: VL 7 Std 64 + self-cooked XFCE-4.10
caitlyn
Packager
Vectorian
****
Posts: 2876


WWW
« Reply #22 on: June 26, 2007, 04:58:19 pm »

To The Headacher:  It's not just Standard.  A slapt-get --upgrade will install gtk+2 2.10.11 into SOHO as well.  It's in both places.  The good news:  It's still only wifi-radar that gets broken.  Anyone going to move wifi-radar 1.9.8 out of testing so that a slapt-get --upgrade doesn't break anything?
Logged

eMachines EL-1300G desktop, 1.6GHz AMD Athlon 2650e CPU, 4GB RAM, nVidia GeForce 6150 SE video
CentOS 6.5 (will try VL64-7.1 soon)

Toshiba Satellite A135-S4727,  Intel Pentium T2080 / 1.73 GHz, 2GB RAM, Intel GMA 950

HP Mini 110 netbook, 1.6GHz Intel Atom CPU, 2GB RAM, Intel 950 video, VL 7.1
joec
Member
*
Posts: 29


« Reply #23 on: June 27, 2007, 04:21:47 am »

If we go the new repo route, I'd rather it isn't called "upgrades" or anything like that, because it sounds confusingly similar to "patches". I would prefer "experimental", or something in that vein. Even "contrib" if necessary... Grin

From one of those new to linux, new to VL (not so good with Windows either) users -- confusion is bad. Smiley The two major issues i have faced are understanding partitioning and figuring out the repositories. VL seems to install with a large list of repositories, mirrors and potential repositories.
It is not always clear where to look for what. A repository for "patches" which only fixes security/bug problems without doing anything else is a good thing.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!