Re: [packman] OBS 2.x and new repository layout
Fredag den 31. december 2010 00:27:12 skrev Pascal Bleser: > Option 1: all-in-one > > > Option 2: divide and conquer > > Option 3: debianista > So, moving as much as possible to relevant build.o.o projects, and only having the stuff that can't go there - e.g. multimedia and p2p etc. - on Packman is not an option? ;-) ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 12/31/2010 07:27 PM, Cristian Morales Vega wrote: > Will not Packman people be able to access this new OBS? (in a limited > way) If people would be able to (easilly) see packages source, build > log and trigger reason; and to create submit request, I would expect > better packages and more trust in those packages. My main problem with > Packman providing packages already available in the main OBS is that > because of this lack of openness I trust more the packages from the > main OBS. > I confess I have the opposite view and I place more faith in the support provided by the Packman packagers. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 12/31/2010 01:08 PM, Pascal Bleser wrote: > The "all-in-one" approach as it is right now is problematic because > there is quite some duplication of packages that are available both in > Packman and in other repositories that exist on d.o.o/repositories > which, in turn, creates package conflicts and "ping-pong" for many users. > Of course, if Packman were to be reduced to things that are only > available on Packman, it would strongly reduce the problem. > >From a user-support perspective, an "option-2" with a split to a small limited number of repositories, with a total number of packages similar to what we see now would also be a viable approach. Of course as support volunteers, we would need to understand the philosophical demarcation, so that those of us who provide volunteer support in areas such as IRC chat and the openSUSE forums (as our openSUSE contribution) could advise and continually support our respective user bases. Reference duplication between Packman and other repositories, while I enjoy the benefit of other repositories (such as what can find with the OBS), I don't always have as much faith in non-Packman repositories, as it is not clear to me what their commitment is to keep their packages on line and up to date. The relative reliability of Packman packager support for their packages has always been a strong point of Packman packaged packages (in my view). I don't know how much one can rely on other 3rd party repositories (which have duplicate rpms) to keep their content, relative to the reliability of Packman. But thats likely another topic, and as long as we see the same availability of Packman packages with any new approach, as we see now, I believe it will be workable from a support provision point of view. Lee ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
2010/12/31 Pascal Bleser : > Dear Packmans :) > (I'm putting the discussion on the public list to give our users a > chance to give their input/preferences as well) > > Detlef was so kind to set up a new (and fresh) OBS 2.1 instance (it's on > another server, the currently running OBS 1.7 instance on pmbs is still > up & running until we switch). Will not Packman people be able to access this new OBS? (in a limited way) If people would be able to (easilly) see packages source, build log and trigger reason; and to create submit request, I would expect better packages and more trust in those packages. My main problem with Packman providing packages already available in the main OBS is that because of this lack of openness I trust more the packages from the main OBS. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Hi; On Fri, Dec 31, 2010 at 7:36 PM, Manfred Tremmel wrote: > ffmpeg makes releases 0.6.1 is released in october. But between 0.5 and > 0.5.1 they found security holes which where fixed fast in svn bot it's > taken two month until 0.5.1 was released so I've desided to build svn > snapshots and not to wait for releases. FFmpeg has a regression testing system which makes SVN version always stable, so packaging SVN is always better because it always have new features. Unless shared libraries are bumped then the reverse dependencies would have to be recompiled too. Best Regards, ismail ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Am Freitag, 31. Dezember 2010 schrieb Pascal Bleser: > On 2010-12-31 14:36:57 (+), Carl Eugen Hoyos wrote: > > Pascal Bleser writes: > > > So the idea with "option 3" would be to provide both: > > > - we would keep the current approach in the "regular" repository > > > (or repositories) > > > - we would also *additionally* provide a frozen repository with > > > the "essential" packages (as said, ffmpeg, mplayer, mad, > > > gstreamer, ...), and only update those when there are critical > > > bugfixes or security fixes > > > > (I of course can't speak for gstreamer - we believe it simply > > serves no real-world purpose and that is of course meant > > polemically - and I don't think any Packman user needs mad, I at > > least can't imagine a situation. Was mad really updated lately?) > > There is nothing "stable" that you could use as "frozen repository" > > in FFmpeg and MPlayer (there were only too few updates to Packman > > MPlayer in the last months). So far, the so-called "releases" > > always were ancient (and therefore unusable) at the time of the > > "release". They only exist because it allows to add FFmpeg to the > > Ubuntu repositories. End-users should never get in touch with them > > (and no bug-reports are accepted for anything else than latest > > svn). While this may sound as if, it is not meant polemically, I am > > just trying to stop you from doing something that does not help any > > user (and you seem to agree that it would mean some extra work)! > > With "stable" I did _not_ mean a "release", at least not for ffmpeg > and mplayer which don't make any releases anyway. ffmpeg makes releases 0.6.1 is released in october. But between 0.5 and 0.5.1 they found security holes which where fixed fast in svn bot it's taken two month until 0.5.1 was released so I've desided to build svn snapshots and not to wait for releases. > > I meant "something that works", and keep it at that version instead > of updating it all the time. > > If we have a combination of ffmpeg, mplayer, vlc, mad, gstreamer and > a few other things that _do_ work, there is no reason for most > people to always get the latest version. It works, that's good > enough for most. Mediaplayers are very security problematic. If you use browserplugins which include MPlayer, xine or VLC you can't be sure not te get an infected stream. I think it's importend to keep up to date and for myselve it's not important what's available as packman package (if svn builds my installed version never gets older then 24 hours). That's the reason I don't have 0.6 or 0.6.1 final package on packman but svn snapshots from time to time. I don't have the time to analyse all the checkins and backport them, sorry. If packman wants a frozen ffmpeg packages with (or without) backports, we need another maintainer for this package. -- Machs gut| http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://packman.links2linux.de/ ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Am Fri, 31 Dec 2010 16:48:39 +0100 schrieb Pascal Bleser : > we can also make an "essentials" thats the name! > repository with just a subset of what we believe most people need or > would like to install (mplayer, ffmpeg, k3b-codecs, xine-codecs, vlc, > gstreamer-bad, gstreamer-ugly, audacity, ... but not something like > claws-mail, and quite some packages are debatable, such as avidemux). We could have a pollsystem, so the pm-users could decide what should be in "essentials". If we have thausend avidemux user, why not add it in "essentials", it doesn't hurd other projects on OBS. essentials -> essential multimedia stuff multimedia -> all other multimedia packages and like a staging repo for essentials other -> all other stuff games -> games or essentials -> essential multimedia stuff main -> all other packages and like a staging repo for essentials games -> games Detlef signature.asc Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Dnia piątek, 31 grudnia 2010 o 13:46:43 Detlef Reichelt napisał(a): > Moin, > > Am Fri, 31 Dec 2010 13:16:18 +0100 > > schrieb Herbert Graeber : > > I would like to have a variant of option 3 on top of option 2: > > > > codecs:11.2 > > multimedia:11.2 > > games:11.2 > > stuff:11.2 > > hm, why codecs and multimedia? > > multimedia (1) > contrib (all other stuff) > games > +1 I like parting a packman repository in that way. The most important is make one repository for all multimedia packages with full libraries (ie, xine, mad, gstremer*, not limited like in obs). > In (1) we should provide all libs and apps which are crippled by > openSUSE (linked to obs) _and_ most wanted apps/libs that are not > shipped with openSUSE, for example vlc/mplayer/mad/ffmpeg etc. > > Newer version of vlc should be build in contrib and if we don't get > bugreports for some time, it could be add in multimedia. > > And if we have directories on vesta like > > openSUSE_11.3/multimedia > openSUSE_11.3/conrib > openSUSE_11.3/games > > we could run a createrepo on openSUSE_11.3 with repodata in > openSUSE_11.3/repodata. So we could offer packman as big > repo too. Never tried this, but should work... ;) > > Detlef > > ___ > Packman mailing list > Packman@links2linux.de > http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman -- Pozdrawiam / Best regards, Mariusz Fik, openSUSE Community Member signature.asc Description: This is a digitally signed message part. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 13:48:49 (+0100), Marcel Gmür wrote: > On Fri, Dec 31, 2010 at 1:53 AM, Pascal Bleser > wrote: > > On 2010-12-31 01:43:22 (+0100), Marcel Gmür wrote: > >> You could also "safe" some build power by simply not building > >> packages, which are already built and maintained at obs, e.g. I had > >> some zypper dup issues with p7zip or some games like openttd. Are > >> those 2 packages really the only ones? > > > > Oh, no, there are many more than those. > > > > There are basically two "positions" on that: > > 1) yes, you're right, it's pointless and there is much more build power > > on build.o.o (also a lot more packagers though ;)) > > 2) we had those packages first, it's not ours to remove, and the people > > who are using the packman repository also use packman because of those > > (and only want to add one big repository instead of a dozen of > > repositories from build.o.o) > > both points are valid, I jsut suggested it according to the lack of > build power. Maybe the obs worker could build for packman too, if > those are idle? No, that's not possible, unfortunately. > about the splitting, will you be able to get all different repos > listed on the yast community repos list? Yes, I can edit that list. > I would also propose a repo for server/network (torrents/monitoring etc.) Maybe, we I think that we all agree that we don't want an extreme granularity either (keep it at 3 or 4 repositories, and not a dozen ;)). cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpsBnBqVoaaG.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 15:32:19 (+0100), Herbert Graeber wrote: > First, you missed the important part of my mail, that is the handling similar > to openSUSE:Contrib, that means having frozen repos for each openSUSE > distribution that can be used without big hassle and unimportant updates by > the average user. > > Am Freitag, 31. Dezember 2010, 13:46:43 schrieb Detlef Reichelt: > > Am Fri, 31 Dec 2010 13:16:18 +0100 > > > > schrieb Herbert Graeber : > > > I would like to have a variant of option 3 on top of option 2: > > > > > > codecs:11.2 > > > multimedia:11.2 > > > games:11.2 > > > stuff:11.2 > > > > hm, why codecs and multimedia? > > I have taken this part from pascals mail. I think pascal wan'ts to take the > essential packages to support mp3 and various video codecs (mplayer, xine, > vlc > and their dependencies) in codecs repository. Everything else should go to > the > multimedia repository. That's the mayjority and the average user does not > need > that stuff. As said, that's just an example, we can also make an "essentials" repository with just a subset of what we believe most people need or would like to install (mplayer, ffmpeg, k3b-codecs, xine-codecs, vlc, gstreamer-bad, gstreamer-ugly, audacity, ... but not something like claws-mail, and quite some packages are debatable, such as avidemux). > > multimedia (1) > > contrib (all other stuff) > > games > > > > In (1) we should provide all libs and apps which are crippled by > > openSUSE (linked to obs) _and_ most wanted apps/libs that are not > > shipped with openSUSE, for example vlc/mplayer/mad/ffmpeg etc. > > There are many multimedia packages really unimportant for most machines. My > mythtv packages for example and some more more related to video and music > production. Agreed, see above. Don't stick on the names though, those were just *examples* :) We need to still sort out the details if we take that path. > > Newer version of vlc should be build in contrib and if we don't get > > bugreports for some time, it could be add in multimedia. > > I am not sure if openSUSE will have a crippled vlc, too. At least there is a > vlc phonon backend, which seems to work better than the xine one. > > > And if we have directories on vesta like > > > > openSUSE_11.3/multimedia > > openSUSE_11.3/conrib > > openSUSE_11.3/games > > > > we could run a createrepo on openSUSE_11.3 with repodata in > > openSUSE_11.3/repodata. So we could offer packman as big > > repo too. Never tried this, but should work... ;) > > I do not like that big mega giga repo. It makes it difficult for me to have > my > small mirror of essential things (eg. the codecs repo) and take the rest out > of the big net. Agreed, but Detlef proposed doing *both* without the need for building everything twice, as the "big" repository would only be a "big" RPM-MD, referring to files that are in the subdirectories: openSUSE_11.3/repodata openSUSE_11.3/multimedia/repodata openSUSE_11.3/multimedia/i586 openSUSE_11.3/multimedia/x86_64 openSUSE_11.3/multimedia/noarch openSUSE_11.3/contrib/repodata openSUSE_11.3/contrib/i586 openSUSE_11.3/contrib/x86_64 openSUSE_11.3/contrib/noarch openSUSE_11.3/games/repodata openSUSE_11.3/games/i586 openSUSE_11.3/games/x86_64 openSUSE_11.3/games/noarch > I think the use of repos could be much easier with explicit Repo dependencies > (Requires, Recommends), like for patterns and packages. So adding a more high > level repo (eg. games) to pull in automatically the more low level ones > (multimedia and/or codecs). True, we don't have that, but it can be documented properly, and a YMP (1-Click-Install) can reference several repositories, where people can pick which parts they want. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpjEzRGJovca.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 14:36:57 (+), Carl Eugen Hoyos wrote: > Pascal Bleser writes: > > > So the idea with "option 3" would be to provide both: > > - we would keep the current approach in the "regular" repository (or > > repositories) > > - we would also *additionally* provide a frozen repository with the > > "essential" packages (as said, ffmpeg, mplayer, mad, gstreamer, ...), > > and only update those when there are critical bugfixes or security > > fixes > > (I of course can't speak for gstreamer - we believe it simply serves no > real-world purpose and that is of course meant polemically - and I don't think > any Packman user needs mad, I at least can't imagine a situation. Was mad > really > updated lately?) > There is nothing "stable" that you could use as "frozen repository" in FFmpeg > and MPlayer (there were only too few updates to Packman MPlayer in the last > months). So far, the so-called "releases" always were ancient (and therefore > unusable) at the time of the "release". They only exist because it allows to > add > FFmpeg to the Ubuntu repositories. End-users should never get in touch with > them > (and no bug-reports are accepted for anything else than latest svn). > While this may sound as if, it is not meant polemically, I am just trying to > stop you from doing something that does not help any user (and you seem to > agree > that it would mean some extra work)! With "stable" I did _not_ mean a "release", at least not for ffmpeg and mplayer which don't make any releases anyway. I meant "something that works", and keep it at that version instead of updating it all the time. If we have a combination of ffmpeg, mplayer, vlc, mad, gstreamer and a few other things that _do_ work, there is no reason for most people to always get the latest version. It works, that's good enough for most. [...] cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpAWENuIwz38.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Pascal Bleser writes: > So the idea with "option 3" would be to provide both: > - we would keep the current approach in the "regular" repository (or > repositories) > - we would also *additionally* provide a frozen repository with the > "essential" packages (as said, ffmpeg, mplayer, mad, gstreamer, ...), > and only update those when there are critical bugfixes or security > fixes (I of course can't speak for gstreamer - we believe it simply serves no real-world purpose and that is of course meant polemically - and I don't think any Packman user needs mad, I at least can't imagine a situation. Was mad really updated lately?) There is nothing "stable" that you could use as "frozen repository" in FFmpeg and MPlayer (there were only too few updates to Packman MPlayer in the last months). So far, the so-called "releases" always were ancient (and therefore unusable) at the time of the "release". They only exist because it allows to add FFmpeg to the Ubuntu repositories. End-users should never get in touch with them (and no bug-reports are accepted for anything else than latest svn). While this may sound as if, it is not meant polemically, I am just trying to stop you from doing something that does not help any user (and you seem to agree that it would mean some extra work)! If you have a bandwidth problem, I suggest to remove win32-codecs, I don't think anybody needs it and it can be downloaded from mplayerhq. Carl Eugen PS: There will be a version bump for libavcodec etc. in the not too far away future and that will of course change your situation slightly. But since it is unknown when it happens and it did not happen for the last two (?) years, I suggest you care about it when it happens. (And such a bump has of course no effect on Packman MPlayer.) ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Moin Detlef First, you missed the important part of my mail, that is the handling similar to openSUSE:Contrib, that means having frozen repos for each openSUSE distribution that can be used without big hassle and unimportant updates by the average user. Am Freitag, 31. Dezember 2010, 13:46:43 schrieb Detlef Reichelt: > Am Fri, 31 Dec 2010 13:16:18 +0100 > > schrieb Herbert Graeber : > > I would like to have a variant of option 3 on top of option 2: > > > > codecs:11.2 > > multimedia:11.2 > > games:11.2 > > stuff:11.2 > > hm, why codecs and multimedia? I have taken this part from pascals mail. I think pascal wan'ts to take the essential packages to support mp3 and various video codecs (mplayer, xine, vlc and their dependencies) in codecs repository. Everything else should go to the multimedia repository. That's the mayjority and the average user does not need that stuff. > multimedia (1) > contrib (all other stuff) > games > > In (1) we should provide all libs and apps which are crippled by > openSUSE (linked to obs) _and_ most wanted apps/libs that are not > shipped with openSUSE, for example vlc/mplayer/mad/ffmpeg etc. There are many multimedia packages really unimportant for most machines. My mythtv packages for example and some more more related to video and music production. > Newer version of vlc should be build in contrib and if we don't get > bugreports for some time, it could be add in multimedia. I am not sure if openSUSE will have a crippled vlc, too. At least there is a vlc phonon backend, which seems to work better than the xine one. > And if we have directories on vesta like > > openSUSE_11.3/multimedia > openSUSE_11.3/conrib > openSUSE_11.3/games > > we could run a createrepo on openSUSE_11.3 with repodata in > openSUSE_11.3/repodata. So we could offer packman as big > repo too. Never tried this, but should work... ;) I do not like that big mega giga repo. It makes it difficult for me to have my small mirror of essential things (eg. the codecs repo) and take the rest out of the big net. I think the use of repos could be much easier with explicit Repo dependencies (Requires, Recommends), like for patterns and packages. So adding a more high level repo (eg. games) to pull in automatically the more low level ones (multimedia and/or codecs). Herbert -- "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 13:46:43 (+0100), Detlef Reichelt wrote: > Moin, > > Am Fri, 31 Dec 2010 13:16:18 +0100 > schrieb Herbert Graeber : > > > I would like to have a variant of option 3 on top of option 2: > > > > codecs:11.2 > > multimedia:11.2 > > games:11.2 > > stuff:11.2 > > hm, why codecs and multimedia? Sorry, was just a random idea :) Maybe it doesn't make any sense to split codecs/multimedia. We'll have to sort out those details :) > multimedia (1) > contrib (all other stuff) > games > > In (1) we should provide all libs and apps which are crippled by > openSUSE (linked to obs) _and_ most wanted apps/libs that are not > shipped with openSUSE, for example vlc/mplayer/mad/ffmpeg etc. Yes > Newer version of vlc should be build in contrib and if we don't get > bugreports for some time, it could be add in multimedia. Hmmm okay, so "contrib" would be some sort of "staging" repository too. > And if we have directories on vesta like > openSUSE_11.3/multimedia > openSUSE_11.3/conrib > openSUSE_11.3/games > > we could run a createrepo on openSUSE_11.3 with repodata in > openSUSE_11.3/repodata. So we could offer packman as big > repo too. Never tried this, but should work... ;) Yeah, I had that idea a long time ago as well, it could work. We'd have to test it first, but it's pretty easy to test. And that could provide both, *if* we don't mix different library versions in multimedia and contrib, as binary packages in multimedia and contrib could be built against different versions of libraries... (unless they are properly ABI/SONAME versioned, then we provide both library packages in the "big" repository but, we know that upstreams don't always get that right). cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpyxEgfKylDU.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On Fri, Dec 31, 2010 at 1:53 AM, Pascal Bleser wrote: > On 2010-12-31 01:43:22 (+0100), Marcel Gmür wrote: >> You could also "safe" some build power by simply not building >> packages, which are already built and maintained at obs, e.g. I had >> some zypper dup issues with p7zip or some games like openttd. Are >> those 2 packages really the only ones? > > Oh, no, there are many more than those. > > There are basically two "positions" on that: > 1) yes, you're right, it's pointless and there is much more build power > on build.o.o (also a lot more packagers though ;)) > 2) we had those packages first, it's not ours to remove, and the people > who are using the packman repository also use packman because of those > (and only want to add one big repository instead of a dozen of > repositories from build.o.o) both points are valid, I jsut suggested it according to the lack of build power. Maybe the obs worker could build for packman too, if those are idle? about the splitting, will you be able to get all different repos listed on the yast community repos list? I would also propose a repo for server/network (torrents/monitoring etc.) ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Moin, Am Fri, 31 Dec 2010 13:16:18 +0100 schrieb Herbert Graeber : > I would like to have a variant of option 3 on top of option 2: > > codecs:11.2 > multimedia:11.2 > games:11.2 > stuff:11.2 hm, why codecs and multimedia? multimedia (1) contrib (all other stuff) games In (1) we should provide all libs and apps which are crippled by openSUSE (linked to obs) _and_ most wanted apps/libs that are not shipped with openSUSE, for example vlc/mplayer/mad/ffmpeg etc. Newer version of vlc should be build in contrib and if we don't get bugreports for some time, it could be add in multimedia. And if we have directories on vesta like openSUSE_11.3/multimedia openSUSE_11.3/conrib openSUSE_11.3/games we could run a createrepo on openSUSE_11.3 with repodata in openSUSE_11.3/repodata. So we could offer packman as big repo too. Never tried this, but should work... ;) Detlef ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Am Freitag, 31. Dezember 2010, 00:27:12 schrieb Pascal Bleser: > Dear Packmans :) > (I'm putting the discussion on the public list to give our users a > chance to give their input/preferences as well) > > Detlef was so kind to set up a new (and fresh) OBS 2.1 instance (it's on > another server, the currently running OBS 1.7 instance on pmbs is still > up & running until we switch). > > To make our lives easier, we decided that we'll migrate the packages > manually, one by one, instead of attempting a server-side migration. > We will lose package history but that's not really much of a problem > (IMHO). That's a good chance to get rid of old nearly unmaintained stuff > The other reason we want to make it manually is that we have a (rare) > chance of setting up a new project layout, as the current one has > several deficiencies. > > So, right now, we need to discuss what we'd like to have. > > Whatever the option, one thing we will definitely do is to enable 11.1, > 11.2 and 11.3 on project-level, hence on all the packages, instead of > having to enable them on every single package as we have it now (which > is really a pain in the ...). That's also how it's managed on > build.opensuse.org, by exception (disable those you don't want to build > or, rather, those that don't work). > > Option 1: all-in-one > > The first option is to have all the packages in a single OBS project, as > we have right now in "main_pm", which we also result in a single, big > packman package repository for users. > > Pros: > + users just need to add a single repository > Cons: > - users have no granularity, it's one big repository with everything > (codecs, multimedia, random updated packages) > - more difficult for us to select a subset of "essential" packages for a > "minimal packman" (i.e. codecs and multimedia), e.g. for Factory and > SLE For some time a had small mirror for all my machines with all this large games,taht are often rebuild because an online updated by SUSE, it became impossible to do that. > Option 2: divide and conquer > > The other extreme is to split the set of packages into several > projects (and, hence repositories) to enable users to pick what they > want to have, e.g.: > * codecs > * multimedia > * games > * stuff > > Of course, and OBS gives us the ability of doing so, we'll have > dependencies between those projects/repositories, like a "layering": > > codecs >^ > >multimedia > .^ ^. > / \ > games stuff > > Pros: > + users can pick what they want from Packman, e.g. only the codecs and > the multimedia stuff > + easier for us to enable a minimal set of things for Factory and SLE > (we just need to enable Factory and SLE11 on codecs and multimedia) > Cons: > - the users who want everything from Packman will need to add more than > one repository (arguably, that's already how it works with > download.opensuse.org) That's the layout I would prefer (as user and as packman). Unfortunately repositories do not have Requires and Recommends dendencies, like patterns and packages have. > Option 3: debianista > > Another approach to "several projects/repos" could also be to split into > stable and unstable or, rather, to freeze the versions of codecs and > multimedia packages with every openSUSE release (and only update on > critical bugfixes and security issues). > > Pros: > + users only need to add one or two repositories and won't get updates > all the time, which will most probably give them a better experience > regarding stability > + OBS can help us, by using links on revisions (from unstable to stable) > Cons: > - potentially more work for us, as it is easier to just bump the version > to the latest than having to only do it when there are security issues > (we will always update to the latest version for the "unstable" > repository/repositories anyway) > > Other options: anything in-between, or combinations thereof. > > Ideas, preferences ? I would like to have a variant of option 3 on top of option 2: codecs:11.2 codecs:11.3 codecs:Factory multimedia:11.2 multimedia:11.3 multimedia:Factory games:11.2 games:11.3 games:Factory stuff:11.2 stuff:11.3 stuff:Factory where the *.11.x projects are built against openSUSE:11.x only and mostly frozen with 11.x release, except for important updates (security, bugs really hurting). I know that backporting patches can be hard, but we can handle this a little more relaxed, like SUSE does for firefox or thunderbird. The important thing is that users can use these repos without that things get broken. *:Factory repos are build against openSUSE 11.x, and Factory and mostly like what we have now. eventually we make it possible to build against newer KDE or Gnome here, too. This is for the experienced users, who know what they are doing. All in all it is a little bit similar like openSUSE:Contrib is handled now
Re: [packman] OBS 2.x and new repository layout
On 2010-12-30 22:39:07 (-0500), todd rme wrote: > On Thu, Dec 30, 2010 at 7:53 PM, Pascal Bleser > wrote: > > On 2010-12-31 01:43:22 (+0100), Marcel Gmür wrote: > >> You could also "safe" some build power by simply not building > >> packages, which are already built and maintained at obs, e.g. I had > >> some zypper dup issues with p7zip or some games like openttd. Are > >> those 2 packages really the only ones? > > > > Oh, no, there are many more than those. > > > > There are basically two "positions" on that: > > 1) yes, you're right, it's pointless and there is much more build power > > on build.o.o (also a lot more packagers though ;)) > > 2) we had those packages first, it's not ours to remove, and the people > > who are using the packman repository also use packman because of those > > (and only want to add one big repository instead of a dozen of > > repositories from build.o.o) > > > > I'm probably exaggerating position 2, and it's not difficult to find out > > which one I'm endorsing *cough*, but it's a somewhat loaded discussion. > > Is there a way you could take advantage of the extra power behind the > "official" obs instance? If we are talking about splitting up the No, probably not, at least not for the stuff that may not be hosted there ^^ > repository anyway, what about splitting off all the packages that > comply with the OBS rules, and building them on the official OBS > system? You can then save your own systems for only building packages > that you cannot build on the official OBS because they violate one or > more of the rules. It would be similar to the Ubuntu method of > splitting packages based on licensing issues, with a "safe" packman > repo hosted in the official OBS system and an "unsafe" packman repo > hosted on your system (those or probably bad names). Yes, bad names, but I see your point :) Yes, of course, that would make sense. But as explained, not everyone in the team has the same opinion on that. Some think that the current approach on build.o.o to have many, many repositories split by purpose/domain is awful and that Packman currently provides the only solution to that issue, as it is a single repository that ships lots and lots of packages (of all sorts). I respect that opinion too, even though it's not mine, but that's why I've started this thread, to weigh the pros and cons of each approach and take a possibly educated choice based on that. Arguably, Tumbleweed might be a solution to that concern, as it will provide a "rolling repository" approach for openSUSE, and then we will have that "big repository" on build.o.o as well. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpMWYzt6x024.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 02:49:06 (+), Carl Eugen Hoyos wrote: > Pascal Bleser writes: > > Option 3: debianista > > > > Another approach to "several projects/repos" could also be to split into > > stable and unstable or, rather, to freeze the versions of codecs and > > multimedia packages with every openSUSE release (and only update on > > critical bugfixes and security issues). > > I'd like to *strongly* discourage this! > Please believe me that this does not solve *any* (possible) problems. > (for FFmpeg and MPlayer, I am not sure what else could be meant with "codecs > and > multimedia packages" and I don't know how well or how badly this would work > for > other projects). Yes, ffmpeg, mplayer, mad, gstreamer*fugly,... How would that be a problem? The idea is that most users just want the codecs and multimedia stuff from Packman (I said "most", not "all"). Or, at least, that's my assumption, which, of course, might be complete wrong :) But assuming so, we always have the strong divide between users who want it to "just work" and favour stability over anything else, and those who want the latest versions to have more features (and performance etc..). Personally, I respect both preferences. Packman as it is right now is best suited for those who want features, as we permanently update our packages with the newest versions. This has several consequences: - things that worked might break, - a "zypper ref" almost always pulls in a lot of megabytes for the Packman metadata + we provide them with the latest and greatest +/- it's pretty much a "rolling" distr^Wrepository Hence, and still in my humble opinion, Packman is well suited for the latter category of users (features) and not well suited for the former (stability). So the idea with "option 3" would be to provide both: - we would keep the current approach in the "regular" repository (or repositories) - we would also *additionally* provide a frozen repository with the "essential" packages (as said, ffmpeg, mplayer, mad, gstreamer, ...), and only update those when there are critical bugfixes or security fixes But that obviously means more work for us. > I don't immediately see what's wrong with 1), but I may not see the important > things there. Option 1 is "all-in-one". Well, I have definitely been poked a few times on IRC about the idea of splitting it, in order to have users only pull the stuff that is available nowhere else from Packman. The "all-in-one" approach as it is right now is problematic because there is quite some duplication of packages that are available both in Packman and in other repositories that exist on d.o.o/repositories which, in turn, creates package conflicts and "ping-pong" for many users. Of course, if Packman were to be reduced to things that are only available on Packman, it would strongly reduce the problem. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpy2g0u431ZI.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
This is a subject a bit 'dear' to my openSUSE use, as I've always held the view that the packages packaged by the Packman packagers was possibly the main reason why I have remained with openSUSE all these years. I am VERY grateful to the efforts of the 3rd party packagers who package for openSUSE, and in particular to those who belong to the Packman packager group. My preferences as a somewhat selfish user (in order of preference from what I would like the most, to the least) would be: Option-3 : debianista Option-1 : all-in-one Option-2 : divide and conquer Having stated the above, I am concerned "Option-3" might make the work load such that the packaging suffers from a quantity perspective, and so Option-3 could easily be 2nd priority to Option-1 in my books. I am concerned that our user base (not our packager, I mean our user base) is not knowledgeable enough to implement the repositories in the Option-2 approach, despite the best/superb efforts of our packagers to make it easy for them. Hence I'm not in favour of Option-2. I like the big "all-in-one" repository approach. Lee aka oldcpu On 12/31/2010 12:27 AM, Pascal Bleser wrote: > Dear Packmans :) > (I'm putting the discussion on the public list to give our users a > chance to give their input/preferences as well) > > Detlef was so kind to set up a new (and fresh) OBS 2.1 instance (it's on > another server, the currently running OBS 1.7 instance on pmbs is still > up & running until we switch). > > To make our lives easier, we decided that we'll migrate the packages > manually, one by one, instead of attempting a server-side migration. > We will lose package history but that's not really much of a problem > (IMHO). > > The other reason we want to make it manually is that we have a (rare) > chance of setting up a new project layout, as the current one has > several deficiencies. > > So, right now, we need to discuss what we'd like to have. > > Whatever the option, one thing we will definitely do is to enable 11.1, > 11.2 and 11.3 on project-level, hence on all the packages, instead of > having to enable them on every single package as we have it now (which > is really a pain in the ...). That's also how it's managed on > build.opensuse.org, by exception (disable those you don't want to build > or, rather, those that don't work). > > Option 1: all-in-one > > The first option is to have all the packages in a single OBS project, as > we have right now in "main_pm", which we also result in a single, big > packman package repository for users. > > Pros: > + users just need to add a single repository > Cons: > - users have no granularity, it's one big repository with everything > (codecs, multimedia, random updated packages) > - more difficult for us to select a subset of "essential" packages for a > "minimal packman" (i.e. codecs and multimedia), e.g. for Factory and > SLE > > Option 2: divide and conquer > > The other extreme is to split the set of packages into several > projects (and, hence repositories) to enable users to pick what they > want to have, e.g.: > * codecs > * multimedia > * games > * stuff > > Of course, and OBS gives us the ability of doing so, we'll have > dependencies between those projects/repositories, like a "layering": > > codecs >^ >| >multimedia > .^ ^. > / \ > games stuff > > Pros: > + users can pick what they want from Packman, e.g. only the codecs and > the multimedia stuff > + easier for us to enable a minimal set of things for Factory and SLE > (we just need to enable Factory and SLE11 on codecs and multimedia) > Cons: > - the users who want everything from Packman will need to add more than > one repository (arguably, that's already how it works with > download.opensuse.org) > > Option 3: debianista > > Another approach to "several projects/repos" could also be to split into > stable and unstable or, rather, to freeze the versions of codecs and > multimedia packages with every openSUSE release (and only update on > critical bugfixes and security issues). > > Pros: > + users only need to add one or two repositories and won't get updates > all the time, which will most probably give them a better experience > regarding stability > + OBS can help us, by using links on revisions (from unstable to stable) > Cons: > - potentially more work for us, as it is easier to just bump the version > to the latest than having to only do it when there are security issues > (we will always update to the latest version for the "unstable" > repository/repositories anyway) > > Other options: anything in-between, or combinations thereof. > > Ideas, preferences ? > > cheers > > > > ___ > Packman mailing list > Packman@links2linux.de > http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman ___ Pac
Re: [packman] OBS 2.x and new repository layout
On Thu, Dec 30, 2010 at 7:53 PM, Pascal Bleser wrote: > On 2010-12-31 01:43:22 (+0100), Marcel Gmür wrote: >> You could also "safe" some build power by simply not building >> packages, which are already built and maintained at obs, e.g. I had >> some zypper dup issues with p7zip or some games like openttd. Are >> those 2 packages really the only ones? > > Oh, no, there are many more than those. > > There are basically two "positions" on that: > 1) yes, you're right, it's pointless and there is much more build power > on build.o.o (also a lot more packagers though ;)) > 2) we had those packages first, it's not ours to remove, and the people > who are using the packman repository also use packman because of those > (and only want to add one big repository instead of a dozen of > repositories from build.o.o) > > I'm probably exaggerating position 2, and it's not difficult to find out > which one I'm endorsing *cough*, but it's a somewhat loaded discussion. > > cheers Is there a way you could take advantage of the extra power behind the "official" obs instance? If we are talking about splitting up the repository anyway, what about splitting off all the packages that comply with the OBS rules, and building them on the official OBS system? You can then save your own systems for only building packages that you cannot build on the official OBS because they violate one or more of the rules. It would be similar to the Ubuntu method of splitting packages based on licensing issues, with a "safe" packman repo hosted in the official OBS system and an "unsafe" packman repo hosted on your system (those or probably bad names). ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
Hi! Pascal Bleser writes: > Option 3: debianista > > Another approach to "several projects/repos" could also be to split into > stable and unstable or, rather, to freeze the versions of codecs and > multimedia packages with every openSUSE release (and only update on > critical bugfixes and security issues). I'd like to *strongly* discourage this! Please believe me that this does not solve *any* (possible) problems. (for FFmpeg and MPlayer, I am not sure what else could be meant with "codecs and multimedia packages" and I don't know how well or how badly this would work for other projects). I don't immediately see what's wrong with 1), but I may not see the important things there. Carl Eugen ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-31 01:43:22 (+0100), Marcel Gmür wrote: > You could also "safe" some build power by simply not building > packages, which are already built and maintained at obs, e.g. I had > some zypper dup issues with p7zip or some games like openttd. Are > those 2 packages really the only ones? Oh, no, there are many more than those. There are basically two "positions" on that: 1) yes, you're right, it's pointless and there is much more build power on build.o.o (also a lot more packagers though ;)) 2) we had those packages first, it's not ours to remove, and the people who are using the packman repository also use packman because of those (and only want to add one big repository instead of a dozen of repositories from build.o.o) I'm probably exaggerating position 2, and it's not difficult to find out which one I'm endorsing *cough*, but it's a somewhat loaded discussion. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgphaE18jI6ap.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
You could also "safe" some build power by simply not building packages, which are already built and maintained at obs, e.g. I had some zypper dup issues with p7zip or some games like openttd. Are those 2 packages really the only ones? Greets Ammler ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On 2010-12-30 19:04:13 (-0500), todd rme wrote: > On Thu, Dec 30, 2010 at 6:27 PM, Pascal Bleser > wrote: [...] > Is there any way to have both, to have separate repositories, then one > master repository that mirrors all the packages from the other > repositories? In theory, yes, and practice too but it would consume twice as much disk space and bandwidth on our mirrors. And twice the build power (as an aggregate probably wouldn't do, as the complete repo could potentially mix different versions of libraries/dependencies). > Another advantage of sub-repositories is that they can be built > against other repositories. For instance the packman games repository > can be built against the OBS games repository, eliminating the need > for redundant packages and preventing conflicts like we have with > allegro. If you did a KDE repository, it could be built against all > the different KDE repositories (KDE:Distro:Stable, KDE:Distro:Factory, > KDE:Unstable:SC, etc) with no additional work on your part. Critical > packages that users might not have available could be linked to the > OBS ones, but would always automatically be kept in sync. This would > mean, for instance, you wouldn't need your own build of K3B, you could > just build the codecs against the version of K3B in each repository. We already do that for many packages. We currently don't build against e.g. KDE:Distro:* because we don't have enough build power (hosts) to do so. > I do think that having proper patterns would be beneficial, if > possible. People should just be able to install, for instance, the > "packman codecs" pattern and it pulls in all of the normally-used > codecs. That's an option as well, independently from the layout. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- I took the green pill _\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org pgpHn09rZ28FO.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] OBS 2.x and new repository layout
On Thu, Dec 30, 2010 at 6:27 PM, Pascal Bleser wrote: > Dear Packmans :) > (I'm putting the discussion on the public list to give our users a > chance to give their input/preferences as well) > > Detlef was so kind to set up a new (and fresh) OBS 2.1 instance (it's on > another server, the currently running OBS 1.7 instance on pmbs is still > up & running until we switch). > > To make our lives easier, we decided that we'll migrate the packages > manually, one by one, instead of attempting a server-side migration. > We will lose package history but that's not really much of a problem > (IMHO). > > The other reason we want to make it manually is that we have a (rare) > chance of setting up a new project layout, as the current one has > several deficiencies. > > So, right now, we need to discuss what we'd like to have. > > Whatever the option, one thing we will definitely do is to enable 11.1, > 11.2 and 11.3 on project-level, hence on all the packages, instead of > having to enable them on every single package as we have it now (which > is really a pain in the ...). That's also how it's managed on > build.opensuse.org, by exception (disable those you don't want to build > or, rather, those that don't work). > > Option 1: all-in-one > > The first option is to have all the packages in a single OBS project, as > we have right now in "main_pm", which we also result in a single, big > packman package repository for users. > > Pros: > + users just need to add a single repository > Cons: > - users have no granularity, it's one big repository with everything > (codecs, multimedia, random updated packages) > - more difficult for us to select a subset of "essential" packages for a > "minimal packman" (i.e. codecs and multimedia), e.g. for Factory and > SLE > > Option 2: divide and conquer > > The other extreme is to split the set of packages into several > projects (and, hence repositories) to enable users to pick what they > want to have, e.g.: > * codecs > * multimedia > * games > * stuff > > Of course, and OBS gives us the ability of doing so, we'll have > dependencies between those projects/repositories, like a "layering": > > codecs > ^ > | > multimedia > .^ ^. > / \ > games stuff > > Pros: > + users can pick what they want from Packman, e.g. only the codecs and > the multimedia stuff > + easier for us to enable a minimal set of things for Factory and SLE > (we just need to enable Factory and SLE11 on codecs and multimedia) > Cons: > - the users who want everything from Packman will need to add more than > one repository (arguably, that's already how it works with > download.opensuse.org) > > Option 3: debianista > > Another approach to "several projects/repos" could also be to split into > stable and unstable or, rather, to freeze the versions of codecs and > multimedia packages with every openSUSE release (and only update on > critical bugfixes and security issues). > > Pros: > + users only need to add one or two repositories and won't get updates > all the time, which will most probably give them a better experience > regarding stability > + OBS can help us, by using links on revisions (from unstable to stable) > Cons: > - potentially more work for us, as it is easier to just bump the version > to the latest than having to only do it when there are security issues > (we will always update to the latest version for the "unstable" > repository/repositories anyway) > > Other options: anything in-between, or combinations thereof. > > Ideas, preferences ? > > cheers Is there any way to have both, to have separate repositories, then one master repository that mirrors all the packages from the other repositories? Another advantage of sub-repositories is that they can be built against other repositories. For instance the packman games repository can be built against the OBS games repository, eliminating the need for redundant packages and preventing conflicts like we have with allegro. If you did a KDE repository, it could be built against all the different KDE repositories (KDE:Distro:Stable, KDE:Distro:Factory, KDE:Unstable:SC, etc) with no additional work on your part. Critical packages that users might not have available could be linked to the OBS ones, but would always automatically be kept in sync. This would mean, for instance, you wouldn't need your own build of K3B, you could just build the codecs against the version of K3B in each repository. I do think that having proper patterns would be beneficial, if possible. People should just be able to install, for instance, the "packman codecs" pattern and it pulls in all of the normally-used codecs. -Todd ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
