On Apr 24, 2011, at 9:16 AM, Felipe Sateler wrote:

On Sun, Apr 24, 2011 at 13:02, IOhannes m zmoelnig <zmoel...@iem.at> wrote:

I see that some bugs (buils system, mostly) will require uploading all
(or most) of the pd externals. Can we do something to avoid that?

hmm, i'm not sure if i understand what you mean:
i thought bugs can only be fixed by providing fixed versions.
if a package is FTBFS because of broken bulid system, then the only solution i
see is to fix the build system and re-upload the package.

the only alternative i see, would be to centralize the build system, e.g. by providing a common makefile snippet that would be used instead of upstream's
build system.

i started centralizing once with a "pd-pkg-tools" library, but it ended up as a cdbs snippet (while almost all of the packages in question right now use
shortform dh).
also the cdbs snippet does not replace upstream build system, but rather fixes debian specifics (e.g. make shlibdeps work nicely with the non- standard

i'm not opposed at all to using a central (separately maintained) makefile, but hans has spent a lot of time crafting the current (upstream) makefile to make it
work with a wide range of systems.
the current template for the (upstream) Makefile already fixes the kFreeBSD/hurd problems, but the packages in question have not been updated (upstream) to use the new template, so i decided to fix the problem using packaging possibilities.

This is the key part: for most pd externals, the makefile is
essentially the same. Does it make sense to centralize that? What do
others think?

I'd like to keep the short-form dh packages that I've done as they are, using this same Makefile. I've spent a lot of time building up a whole workflow to fit well into dh style, which is the dominant system of Debian-NYC which I'm part of, and the upstream workflow. Its great that there is also CDBS stuff, but for the stuff I maintain, I don't want to switch.



If you are not part of the solution, you are part of the problem.

pkg-multimedia-maintainers mailing list

Reply via email to