Re: Cross-distro collaboration for lcdproc packaging ?
Markus Dolze <[email protected]>
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
On 22.03.2011 19:53, Jarod Wilson wrote: > On Mar 22, 2011, at 2:44 PM, Dominique Dumont wrote: > >> Hello >> >> I've prepared an update of lcdproc package for Debian. Instead of keeping the >> work for myself and my distro, I think it would be more interesting for >> everybody to be able to share the work. >> >> For this, we have some choices on how to proceed on sharing work. >> >> First on sharing knowledge (i.e. where should we discuss packaging issues): >> - Create and use a lcdproc-packaging mailing list >> - use this list >> >> For sharing packages files: >> - Fling patches around on a mailing list >> - create a separate repository for package files >> - archive package file on lcdproc upstream CVS. >> >> Personally, I think lcdproc project would probably learn interesting stuff >> from packaging issues, so I would favor using this list for packaging >> discussion (as long as it does not generate too much traffic). >> >> Regarding package files, the best would be the latter option. Once we decided >> on the best way to share files, I'll send the files I've prepared for Debian. >> >> What do you think ? >> >> Are there other distro packagers lurking on this list ? > I am (or was?) one of the co-maintainers of the Fedora lcdproc > packages. Or maybe I've just committed to them. Regardless, I know > the Fedora packaging process pretty well. An rpm spec file really > doesn't belong in the upstream scm, as far as I'm concerned. They > are far too distro-specific, and often need updating by people > other than those without core package scm commit access. Even if > the Fedora spec were added to an upstream scm repo, it would have > to be duplicated into Fedora's packaging scm, and then maintained > in two different places. No thanks. :) > > As for patches, all of them should be posted to this list for > consideration for merging. Ideally, your package shouldn't have to > carry any patches at all for any extended period of time. Knowing > some of the non-patch hacks done via scripting in package creation > tools/specs/whatever could be useful to air as well, to make them > unnecessary, so I suppose at least periodically reviewing packaging > files wouldn't be such a bad idea. > Hi there, actually we removed official Debian packaging support files from our source tarball some time ago. Most distributions have their own way of creating packages, including the necessary infrastructure to build, sign and distribute them. In addition each distribution requires knowledge on how dependencies between packages are to be handled. While we do try to support multiple platforms and include workarounds for specific platforms and versions, maintainers may have different preferences than we have (e.g. which drivers or files to install, install location etc.) For LCDproc it does not make sense to create or distribute binary packages in any way therefore. Additionally I prefer not to include package building information nowadays. Looking at the number of distributions available (Distrowatch counts over 300) multiplied with the number of platform (counting 10 for Debian) is just nothing I want to deal with. Scripts/debian is already an exclusion and if you look at it you find it unmaintained So, if you have created some updates for Debian builds I am happy to commit it to scripts/debian. Even if we don't maintain package building information ourselves it does not mean we are ignoring other's work. Occasionally I check some major Linux distributions (Debian, Ubuntu, Fedora) for patches we may incorporate and I appreciate more feedback 'upstream'. On the other side not everything may be included (this is currently true for drivers Debian/Ubuntu ship on their own). Patches may be sent to this mailing list as usual or the Sourceforge tracker, although you may reach more maintainers by the the list. We may also set up some different mailing list for this. Regards, Markus