Hi Maciej, Am 05.10.2013 um 12:44 schrieb Maciej Bliziński <[email protected]>: > On Sat, Oct 05, 2013 at 12:32:36PM +0200, Dagobert Michelsen wrote: >> Hi Maciej, >> >> Am 05.10.2013 um 11:37 schrieb Maciej Bliziński <[email protected]>: >>> We either should package them well or not package them at all. Packaging >>> them well requires additional time and effort, which we simply don't >>> have. Is running "svn up" really that hard? >> >> >> It may be in fact a good idea at some point to really release it as package > > I'm not against it, but benefits don't outweigh the costs in my opinion. > Of course, if anyone cares enough, feel free to put in the work to > package it, which involves: > > - refactoring the code so it can be packaged at all (requires writing > a setup.py and modifying the code itself) > - writing the build recipe > - testing the package > - writing up the release procedure > - later on, potentially supporting multiple versions of the code > - either making sure that it can work from both sources and the package, > or modifying GAR so that we're only using it from the installed > package in the buildfarm > - making sure that it's possible to work on a development version so > that we can continue improving the code > > It's too much work an too little gain.
I see. I was more thinking of taking the files and putting them in a package :-) This was probably too simply thought... >> to allow easy rebuilding. > > Not sure if I understand. Do you mean, easy rebuilding of which code? Ah, forget it. I am confused this morning. I thought of allowing people to package up binary stuff we aren't allowed to distribute like jdk or the oracle client, but that requires a gar package, not a pkgdb package. Sorry for the noise. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
