Paul Gevers:
> Hi Ximin,
> On 28-11-16 04:03, Debian FTP Masters wrote:
>>  jquery-ui-themes (1.12.1+dfsg-1) unstable; urgency=medium
>>  .
>>    * New upstream release.
>>    * Remove most redundant stuff from orig tarball.
>>    * Add myself to Uploaders.
> I looked into updating jquery-ui-themes myself, some weeks ago, but I
> failed to find the upstream SOURCE of the package.¹ I don't think you
> have either. I'd like to hear your opinion on my earlier message.

Hi Paul, I don't really want to spend any further of my personal time with JS 
and its time-wasting ecosystem of pretentious bullshit software, so I couldn't 
care less about this topic. Sorry, this is not meant to be personal. I am sick 
of good software engineers being forced to clean up other people's crap, who 
can't be bothered doing it themselves or listening to advice that they're doing 
it badly.

However I will note that what I did, strictly improved the situation from what 
it was previously - if you look at my package, you'll note it does build quite 
a lot of things already, the only things left are:

- themes/x/images/*
- themes/x/theme.css

I imagine that one could reverse-engineer a "template" for each of these and 
then write some scripts yourself to re-parameterise the template. For example, 
you can do this

$ diff -ru themes/{smoothness,start}/theme.css | colordiff | less -R

to see what is actually being changed. As for the images, they look like they 
only differ in the shade of color.

However, as I said I really don't give enough of a shit to figure this out 
personally, and I have lots of other things to do with my time. I can agree 
this is not the "preferred form of modification" but OTOH I also don't think 
users will care that much about this, for DFSG purposes.

It looks like upstream don't give a shit about open-sourcing theme-roller, see 
the user complaints here:


I would support removing this type of anti-FOSS attitude from Debian *on 
principle* but also don't really want us as a project to waste more time on 
this bullshit. The more time we spend on this, the less time we spend on doing 
more constructive things, and we're losing out in both cases.

If you decide to file a RM for this package, I would suggest adding an obvious 
alternative binary package that developers like myself can easily find (see the 
time-saving principle here?) that can advise us on what to do, if one of our 
packages uses a JQuery UI Theme and it's not available in Debian.

That is the only reason why I packaged this myself; I wasn't sure if using the 
"base" theme would affect the-package-that-I-actually-want-to-package in 
negative ways - for example some 3rd-party applications hard-code the path to 
theme-specific images, that don't exist in the base theme.

> Regarding commit 14334b6, you are not allowed to generate debian/control
> while building the package.²

If you look at the .debian.tar.xz I uploaded, you will see that it does contain 
debian/control, so it satisfies everything in that FAQ you linked:

1. everything must be defined at the beginning of the build. - check
2. do not modify that in the running build-process - even if the build rule 
somehow gets activated, this would just re-generate the exact same contents as 
what is already there, so it wouldn't get "modified".


> ¹
> ² (see debian/control
> breakage #2)

GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Pkg-javascript-devel mailing list

Reply via email to