-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Youssef CHAHIBI wrote:
Actually, there were a lot of discussions about packaging these days which covered many aspects of the problem.
Not even near half the aspects of the "problem" ;)
I am then writing this article to discuss and sum up what we should do. This isn't a question nor an answer, it's a invitation for everybody to build ideas and concretise our wishes. On the first hand, I'd like to discuss the packaging process, architecture, etc... I am still a novice but may be my suggestions would be welcome. - The first issue, as far as I know, is unified technical standards to build rpms. This issue should be adressed to Novell/SUSE, after analysing the technical documetation presented in Novell's website and looking for missing information. A build server should be created.
"Unified technical standards" ? What we need are policies, or call them guidelines if you prefer. What's on Novell's forge definately is part of that, but it's not going far enough. It's not about being "strict" or raising the bar for new/unexperienced packagers to join in. It's to help ensure that the packages 1) work 2) fit well into the distribution 3) play nice with packages from others 4) provide a consistent experience to the end users The build server infrastructure will be set up by Novell, it's on the roadmap. Don't know yet what it will look like, but it will be provided. Note that IMHO the build servers won't solve any issues, it's about policies, peer review, communicating between the 3rd party packagers. That's how we can solve the issues that will arise.
- If they gave a positive reaction, then the next issue would be RPM trees, I suggest the following branches:
Explain what your understanding of such "branches" is, applied to packages. Should those be separated YaST2 installation sources ? Do you want all the packagers to have a single upload location, a single repository ? (that approach has serious drawbacks IMHO) If not, how do you want to aggregate them ?
+ official : RPMs approved by the OpenSUSE community, ( could be the current inst-source repository )
"approved by the openSUSE community" - - who is approving ? - - how to implement the approval process ? - - approval processes are slow, tedious, not effective The current inst-source is the core distribution: SUSE Linux OSS. That is currently under control of Novell. We (community) and they (Novell) don't have plans yet on how and whether to open that control. Please read the past mails about this on the list archive.
+ community : Unofficial RPMs, built by volunteers from all over the community, after testing, migration to official must be approved by the community, ( respects patents, open source )
Again, how do you think we could implement an efficient approval scheme ? Who is going to test them ? How ? Please read the past mails about this on the list archive.
+ java : Due to the importance of Java applications, java packages should have their own branch.
Err.. now I really don't see what your concept of "branches" is, here. And doesn't that staging (official / community) apply to Java packages ?
+ extra : free redistributable packages ( non open source ), may contain dummy packages with scripts to download and install commercial packages ( ATI, NVIDIA, firmwares) like YOU. + nonfree : open source packages with licensing problems ( MP3, dvd playback, win 32 codecs ... )
There are a lot of issues with those, it definately needs a lot of thinking, discussing and counterchecking the constraints. The hosting of those could be problematic as well.
( In parallel , there should be another "devel" tree containing the same branches )
And what's the difference between devel and non-devel ? Please define what you're thinking of. Throwing one-liners without any definitions won't bring us further.
At this state, OpenSUSE would be in a better shape. And the commnity would be able to concentrate on more exotic projects ( My ideas : SUSE Live CD creator ; Yast package installation in command line ( install <package> uninstall <package> ) with compatibility with many repositories ) ; Klik for SUSE ; Server Edition, Network Firewall Edition, .... )
"Yast package installation in command line" -> y2pmsh, we already have that ;)
The real questions are: Who can do manage this ? How can Novell help us ? ....... Please critisize, comment, suggest.
Sorry if I sound rude here, but...
Did you actually read all the posts that we've already made about this topic ?
Why are you writing yet another mail about it, starting the discussion again at 0, and throwing
one-liners without further details ?
You're not even mentioning, referring to or commenting on what has already been written.
And here's a summary of that as well: http://www.opensuse.org/Packager
Great to give your ideas, we definately need more people involved into the discussion, it's open to
everyone to contribute their brain cells ;) but you're just discarding the many hours a few of us on
this list have spent in already discussing some of those aspects.
Well, speaking for myself, I have spent several hours on it, and I kinda feel pissed because you
start the whole discussion again without taking anything that has been said about it into account.
Please pick up the mails we've already written, read them and comment on those.
http://www.opensuse.org/Packager
http://lists.opensuse.org/archive/opensuse/2005-Sep/0200.html
http://lists.opensuse.org/archive/opensuse/2005-Sep/0430.html
That would be much more productive for everyone ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\