Re: Uploading python-xstatic-* packages in Debian
On 08/15/2014 12:28 AM, Jonas Smedegaard wrote:
> Quoting Thomas Goirand (2014-08-14 09:26:05)
>> Note that the XStatic python modules aren't just meta packages, they
>> also offer a mechanism for a Python script to discover where to find a
>> given static file in the system (which really, isn't obvious, as the
>> Debian archive is a bit messy in this regard, especially when dealing
>> with static files that aren't javascript like .css or .less files).
>
> You are quite welcome to propose tp relevant teams streamlining which
> could ease your packaging. A cleanup might take time to coordinate, and
> agreeing on tidying the structure may take time too, but that shouldn't
> discourage you from initiating that process :-)
>
> I recommend to discuss that in those smaller teams rather than here.
Well, unfortunately, I'm not sure there's a solution, or at least, I
don't have it. Things are the way they are because upstream decided to
put this or that file in this or that folder, and then every upstream
has his own convention. Then we just follow upstream, and that is a good
thing. But at the end, we end up with no convention. A more broad
standard should, at some point, be establish, so that everyone (and by
this, I mean also upstream authors...) sorts files in the same way.
Anyway, this was just a few thoughts, I didn't intend to start a troll
thread about this. :)
>> For some XStatic packages, the embedded static files are not present
>> in Debian. That is the case for example with python-xstatic-hogan,
>> python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the
>> above 3 packages, the upstream source code is part of a much larger
>> project.
>
> Please don't embed reusable non-Python code into Python-specific
> packages - then you end up with same problem as you ran into yourself
> with ruby-bootstrap-sass (see right below). Instead, package (or
> request others like the Javascript ot Sass team) to package those which
> you need.
I'm doing the libjs-* packages whenever that's not too big, and
manageable by myself. I did that for libjs-twitter-bootstrap-datepicker
for example, then I just depend on that package.
>> See for example bootstrap-scss, which comes with a huge Ruby
>> framework. I have no intention to package all of that...
>
> I guess you mean ruby-bootstrap-sass - please see bug#739783.
Oh, sweeeet! What I need is in compass-bootstrap-sass-plugin :)
Thanks a lot for the pointer, Jonas. This is really helpful.
Indeed, #739783 is important to be fixed for me as well, as I wont be
using ruby at all, and I don't think it's reasonable to get 10MB of
non-useful ruby stuff for Horizon ! :)
>> As I know very little about packaging of some upstream code (for
>> example, I have never maintained ruby or nodejs packages), and that I
>> don't need them anyway (I only need a few javascript files from them,
>> I will have no use of Ruby or nodejs code), then I decided to *not*
>> package the full upstream package, and leave the embedded copy inside
>> the python-xstatic-* packages. This is until someone needs the full
>> upstream package, at which point I will remove the embedded copy, and
>> point to the relevant files inside the recently uploaded package.
>
> Please don't postpone proper packaging until others eventually steps up.
Theoretically, you are right. Unfortunately, this isn't practical.
I'm sorry, but I just can't package stuff that I have no use for, or for
which I have no knowledge (ruby is a good example of this). This will be
bad work, and I don't want to upload crap which I wont even be able to
check by myself. It would also sometimes be too much work, for which I
wont have time for.
I also don't believe that just writing an RFP will make it happen. If
this was the case, I'd just do that, always, and stop doing any sort of
packaging myself...
So, I'm going to do this only as much as I can, when possible. I hope
you'll understand.
Cheers,
Thomas Goirand (zigo)
Reply to: