Re: alternative debian/rules
Niels Thykier niels at thykier.net writes: No, not out of the box. I believe it is supported via dh-exec and debhelper compat 9 (though only available in Wheezy, so if you are regularly backporting to older versions of Debian ) But using dh-exec kinda defeats the entire purpose of switching to debhelper in the first place… unless it’s only a little bit in an otherwise descriptive package, possibly the dh7 three-liner, sure. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130428t221838-...@post.gmane.org
Re: alternative debian/rules
Russ Allbery rra at debian.org writes: Lars Wirzenius liw at liw.fi writes: On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote: For the record, I completely disagree with this packaging advice. Why carry an upstream patch when you can handle this easily during build time? Right. As much as I dislike quilt, at least it makes it easy to see what change Debian is making, with regards to upstream. Embedding commands into It’s a package that goes otherwise unpatched, and as such, patches would add a lot of (visual and other) overhead. Additionally, I keep my packages and patches in a VCS, with the patched tree in VCS but not any patches, and use single-debian-patch to generate the quilt stuff, since that was what I got during the DebČevapćičiConf talk on using git for packaging is the only sane thing to do, and that would be easily more obfuscating than those lines. (Using three separate lines instead of a loop prevents needing case handling for pax.1 and is common to people used to BSD make.) I tend to do this sort of manipulation in debian/rules instead of in a patch when whatever I'm doing feels like enabling an upstream option And precisely that, it is: The register-setting command, prepended in front of the nroff source, enables the upstream option for e.g. the cpio(1) manpage to identify itself as paxcpio(1) manpage. Neil, honestly, I’m shocked that this is the most important point of the pax packaging to you. Who are you to decide that a simple echo|cat prepending is obfuscating? Indeed, if this scares you you’d better keep your hands off my packages. I agree that having other DDs being able to patch the packages in case of need is good, but that doesn’t mean that *every* other DD should do it. I don’t generally touch Python packages, or library packages, for that matter, until I need to do (and then have read up on the relevant policies etc.) either. (Besides, this part of the build system is *working* _and_ upstream- approved. Easy, since I’m upstream. So don’t tell me what to do. Oh, and I use it in packaging for other distros, too.) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130427t182559-...@post.gmane.org
Re: alternative debian/rules
Russ Allbery dixit:
That code adds the line .nr g 2 to the start of cpio.1 and adds it to
the package as paxcpio.1.gz.
Incidentally, there is a massive limitation of the debhelper tools:
THEY CANNOT RENAME FILES.
I’ve had to add code to debian/rules in *several* packages to copy
or rename files inside a build tree so debhelper declarative style
can pick them up and place them correctly. This is why I feel it’s
sometimes inadequate. It’s a great tool, don’t take me wrong (well
dh5 style is…), but only for *most*, not *all*, packaging situations.
By the way (don’t take this paragraph too serious), let me plug an
advertisement for two Launchpad groups (similar to those LP groups
like “people who don’t work for Canonical but are mistaken for them”):
https://launchpad.net/~cdbs-haters and https://launchpad.net/~dh7-haters
..ie \ng==1 \{\
..Nm mircpio
..Nd copy file archives in and out
[…]
This is normal *roff code familiar to anyone who writes *roff. The above
is a reasonably elegant
Incidentally, there comes the second limitation of Debian tools:
I first had set string variables based on \ng and used them in
the .Nm macros etc. to avoid duplication like this. But some of
the Debian tools and stuff like makewhatis didn’t like this as
they seem to parse the .Nm/.Nd lines directly, so this became a
tad less elegant.
Personally, I like the BSD solution best: we do
nroff -mdoc -rg1 cpio.1 mircpio.cat1
and install the preformatted manual page. But in the Debian
ecosystem, manual pages have to be installed as gzip(1)d
unformatted nroff pages, so it was done like that.
One last thing: Andrey Rahmatullin wrote:
And I thought it was about freedom of choice.
Linux is not about choice
Debian is not (just) about Linux.
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1304271637530.13...@herc.mirbsd.org
Re: alternative debian/rules
Guillem Jover guillem at debian.org writes: Thorsten, OTOH the deb format has supported GNU ar generated archives for a very long time, it's documented in the man page. So while using Right. I’ve been building for sarge and dapper occasionally, and etch and hardy regularily, and supporting roughly a hundred company desktops on hardy, while building the packages. Many of my packages were done in a personal repository first and then introduced to Debian proper (often with changes, although I tend to follow Policy as much as possible/reasonable even in my personal repos), and until only some weeks ago, I did in fact do active backports to *at least* lenny for all of my stuff and some stuff from Debian. So I try to be a bit more compatible. Of course, Debian proper builds in sid, and maintainer script and dependency stuff for older than oldstable is generally cleaned up, but that doesn’t prevent me from keeping things in or at least making it easy to backport. Oh well: the APT tools to preconfigure packages in hardy could not deal with SYSV ar archives. Thus. GNU ar to build deb:s should be generally discouraged when there's dpkg-deb around, it should also be considered a supported action. Okay. But that doesn’t make using pax to build them unsupported; rather, it’s better than ELF GNU ar… People have said they like the “dogfooding” aspect of using pax to build the pax .deb though – and that was part of the intention. For mksh it was an experiment (whether I could get one of the d-ports to build it), which failed in the end (though I could get responses by approaching the porters directly), so I don’t have a reason to not use dpkg-deb there (although I’m still somewhat angry about the rest of the things; mksh and pax are no longer officially cross- buildable since the forced switch to debhelper). So, in the end, I agree on some of the things and would probably have willingly changed them, but using debhelper just for the sake of using a helper, and the tone (and threat to RM), *and* being singled out, sit sour. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130427t184627-...@post.gmane.org
Re: alternative debian/rules
On 2013-04-27 18:45, Thorsten Glaser wrote: Russ Allbery dixit: That code adds the line .nr g 2 to the start of cpio.1 and adds it to the package as paxcpio.1.gz. Incidentally, there is a massive limitation of the debhelper tools: THEY CANNOT RENAME FILES. No, not out of the box. I believe it is supported via dh-exec and debhelper compat 9 (though only available in Wheezy, so if you are regularly backporting to older versions of Debian ) ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517c1afc.3080...@thykier.net
Re: alternative debian/rules
On Mon, Apr 22, 2013 at 09:38:14AM +, Thorsten Glaser wrote: Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. And I thought it was about freedom of choice. Debian is not really freedom of choice, we put quite a lot of restrictions in the debian policy on what you may or may not do in debian packages. debian/rules is a bit of odd exception, where we tightly regulate the output the file must produce, but the actual contents of the file is a wild west. That is a major source of pain when doing archive wide changes - no using build-arch target at buildd's for you! Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424082805.ga30...@afflict.kos.to
Re: alternative debian/rules
On 04/22/2013 06:09 PM, Jakub Wilk wrote: #690381 Gosh, what a shocking thread... I didn't read until end, but nearly at half of it, it felt bad already. Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. Agreed. Especially when I see that this: echo .nr g 2 | cat - cpio.1 | \ gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1.gz is called obfuscation, then doom it as unacceptable for the archive. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5177c1dd.8080...@debian.org
Re: alternative debian/rules
* Timo Juhani Lindfors timo.lindf...@iki.fi, 2013-04-22, 13:22: Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. Was there perhaps some emoticon missing? Sorry, yes, this one: :/ Uncommon debian/rules setups might be required in some cases but surely they should not be used to intentionally make it harder for other developers to understand? Of course, scaring certain developers away should never be a goal. It can be a nice side-effect, though. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424142542.ga5...@jwilk.net
Re: alternative debian/rules
On Wed, Apr 24, 2013 at 04:25:42PM +0200, Jakub Wilk wrote: * Timo Juhani Lindfors timo.lindf...@iki.fi, 2013-04-22, 13:22: Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. Was there perhaps some emoticon missing? Sorry, yes, this one: :/ Uncommon debian/rules setups might be required in some cases but surely they should not be used to intentionally make it harder for other developers to understand? Of course, scaring certain developers away should never be a goal. It can be a nice side-effect, though. I'm sorry, but can I just clarify: do you think that it's an advantage that your custom debian/rules prevents others from understanding your package? Neil -- signature.asc Description: Digital signature
Re: alternative debian/rules
On 04/24/2013 10:39 PM, Neil McGovern wrote: I'm sorry, but can I just clarify: do you think that it's an advantage that your custom debian/rules prevents others from understanding your package? Neil I don't think anyone ever wrote that. Jakub was quite clear, IMO. If you are scared by echo x | cat - y, that it prevents you from understanding the rules files, then you shouldn't touch the package anyway. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5177f814.30...@debian.org
Re: alternative debian/rules
On Wed, Apr 24, 2013 at 11:19:48PM +0800, Thomas Goirand wrote: On 04/24/2013 10:39 PM, Neil McGovern wrote: I'm sorry, but can I just clarify: do you think that it's an advantage that your custom debian/rules prevents others from understanding your package? I don't think anyone ever wrote that. Jakub was quite clear, IMO. No, he wasn't. Which is why I wanted to clarify. If you are scared by echo x | cat - y, that it prevents you from understanding the rules files, then you shouldn't touch the package anyway. If you're deliberately obfuscating debian/rules when there's no or very little advantage, then you shouldn't be producing the package. Neil -- signature.asc Description: Digital signature
Re: alternative debian/rules
On 04/25/2013 12:10 AM, Neil McGovern wrote: If you're deliberately obfuscating debian/rules when there's no or very little advantage, then you shouldn't be producing the package. I'm not the one claiming that using echo and cat is obfuscation! Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5178156c.2050...@debian.org
Re: alternative debian/rules
On Thu, Apr 25, 2013 at 01:25:00AM +0800, Thomas Goirand wrote: On 04/25/2013 12:10 AM, Neil McGovern wrote: If you're deliberately obfuscating debian/rules when there's no or very little advantage, then you shouldn't be producing the package. I'm not the one claiming that using echo and cat is obfuscation! Perhaps you should go read the bug report first. As you seem to be unwilling to actually do research, I'll include the relevant section for your benefit: - 1: deliberate obfuscation for no benefit: echo .nr g 2 | cat - cpio.1 | \ gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1.gz Just add the extra top line to the upstream or create a patch already. then you'd have something approaching sane: cp cpio.1 debian/pax/usr/share/man/man1/paxcpio.1 gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1 Even that is two lines repeated three times (once for each manpage) instead of just dh_installman on a single line and a small .install file but that just demonstrates the insanity of the current rules. Neil -- signature.asc Description: Digital signature
Re: alternative debian/rules
Thomas Goirand z...@debian.org writes:
Agreed. Especially when I see that this:
echo .nr g 2 | cat - cpio.1 | \
gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1.gz
is called obfuscation, then doom it as unacceptable for the archive.
I'm generally in favor of using standardized packaging tools, and I think
it's better to not use hand-rolled build systems (although we're still
doing it for Policy for I think justifiable reasons). However, the above
is not in the slightest bit obfuscated; I also have to object to that.
That code adds the line .nr g 2 to the start of cpio.1 and adds it to
the package as paxcpio.1.gz. There's nothing obscure about that -- it's
all standard UNIX tools that most Debian packagers should be familiar with
-- except for the .nr g 2 part, and that's just because not everyone
reads *roff. A random hunk of Haskell code is equally obscure to me, but
that doesn't mean Haskell is obfuscated.
For the record, .nr g 2 sets the g register to the value 2. From context,
I bet upstream ships a man page that can generate either cpio or paxcpio
documentation and switches between them based on the setting of the g
register.
I wrote the above paragraph without looking at the file, just to keep
myself honest, and have now looked at the file, and it's exactly what I
thought except that it actually switches between mircpio, paxcpio, and
cpio:
.Sh NAME
.ie \ng==1 \{\
.Nm mircpio
.Nd copy file archives in and out
.\}
.el .ie \ng==2 \{\
.Nm paxcpio
.Nd copy file archives in and out
.\}
.el \{\
.Nm cpio
.Nd copy file archives in and out
.\}
This is normal *roff code familiar to anyone who writes *roff. The above
is a reasonably elegant way of handling generation of the paxcpio man page
that minimizes code duplication. There's nothing objectionable about it.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo93x0lv@windlord.stanford.edu
Re: alternative debian/rules
Hi! On Mon, 2013-04-22 at 09:38:14 +, Thorsten Glaser wrote: Adam Borowski kilobyte at angband.pl writes: It can be done Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. I went through (the long and repetitive) #690381, and I think the threats there to unilaterally request for package removals are completely out of place, more so when it comes to _requesting_ a packaging style switch, which should be at most wishlist (if at all). For things like this, people should be convinced with arguments not by appeals to authority or force. And then I'm not much convinced by the arguments presented there, are we so accustomed to the various helper tools that we've forgotten basic make and shell stuff? Don't get me wrong, I'm all for unified packaging, and in my ideal world we'd have a single, clean and elegant style/toolset able to handle all needs (equally for trivial or complex packages), easily extensible for global changes, etc, which I don't think we currently have. But at the same time Debian has always been characterized by its decentralized autonomy, which has allowed all different kinds of experiments to flourish, and people have selected the solutions with best merits (following Debian's meritocratic nature); or using the best tool for the job in the maintainer's opinion. Coercing everyone into the hive-mind will make us miss the next nicer solutions. Thorsten, OTOH the deb format has supported GNU ar generated archives for a very long time, it's documented in the man page. So while using GNU ar to build deb:s should be generally discouraged when there's dpkg-deb around, it should also be considered a supported action. (I mean, I see the point, but as long as things like cdbs or the, for many people unmaintainable due to being “too magic”, dh7 style are around… it’s unfair!) Yeah, the day using debhelper means having to use dh-style rules, I'll switch to something else. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424184332.ga...@gaara.hadrons.org
Re: alternative debian/rules
Neil McGovern ne...@debian.org writes: On Wed, Apr 24, 2013 at 11:19:48PM +0800, Thomas Goirand wrote: If you are scared by echo x | cat - y, that it prevents you from understanding the rules files, then you shouldn't touch the package anyway. If you're deliberately obfuscating debian/rules when there's no or very little advantage, then you shouldn't be producing the package. I think you're expressing a bit too much confidence in the universality of your personal reaction here. Just because it isn't clear to you doesn't mean that it's obfuscated, let alone deliberately obfuscated. I think you have the core of a reasonable point -- it's probably better for the archive as a whole if we can standardize as much as possible on packaging tactics since it makes it easier for other people to work on packages they've not seen before -- but you're applying it a bit too aggressively to some debian/rules constructs that I would be unsurprised to see in any package, including ones using dh. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gjrwy6b@windlord.stanford.edu
Re: alternative debian/rules
Neil McGovern ne...@debian.org writes: Perhaps you should go read the bug report first. As you seem to be unwilling to actually do research, I'll include the relevant section for your benefit: - 1: deliberate obfuscation for no benefit: echo .nr g 2 | cat - cpio.1 | \ gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1.gz Just add the extra top line to the upstream or create a patch already. then you'd have something approaching sane: cp cpio.1 debian/pax/usr/share/man/man1/paxcpio.1 gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1 For the record, I completely disagree with this packaging advice. Why carry an upstream patch when you can handle this easily during build time? The important point here is not whether I'm right or Neil is right. It's that it's a matter of opinion and personal preference, and therefore I don't think it's an area where we should be telling other developers what to do. (Note that this is separate from the more general question of whether it's worthwhile to push everyone towards using debhelper or dh or some equivalent like CDBS.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwsnvjet@windlord.stanford.edu
Re: alternative debian/rules
On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote: For the record, I completely disagree with this packaging advice. Why carry an upstream patch when you can handle this easily during build time? As much as I dislike quilt, at least it makes it easy to see what change Debian is making, with regards to upstream. Embedding commands into debian/rules that modify the sources during a build is much harder to spot. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424193134.gd8...@havelock.liw.fi
Re: alternative debian/rules
Lars Wirzenius l...@liw.fi writes: On Wed, Apr 24, 2013 at 12:05:30PM -0700, Russ Allbery wrote: For the record, I completely disagree with this packaging advice. Why carry an upstream patch when you can handle this easily during build time? As much as I dislike quilt, at least it makes it easy to see what change Debian is making, with regards to upstream. Embedding commands into debian/rules that modify the sources during a build is much harder to spot. There are a lot of different things that can fall into the category of changes to upstream. debian/rules contains all the logic to pass arguments to configure or pass special flags to the compiler, for example, which can often have much more wide-spread changes than modifications to files. That's also the place where we often rearrange all the installation paths that upstream uses, or install separate configuration files that don't come from the upstream source. If debian/rules is using something like dh (which I realize wasn't the case here), the changes tend to stand out. I find it easier to read a succinct debian/rules file to see what special work the packaging is doing relative to the dh defaults than to analyze patches. I tend to do this sort of manipulation in debian/rules instead of in a patch when whatever I'm doing feels like enabling an upstream option rather than modifying upstream source code. That's particularly the case when I'm also upstream; for various psychological reasons, I really prefer not to carry Debian patches when I also control the upstream source. To me, this specific case (activating one of three possible output formats for a man page) feels more like an option than like a source code change, since the infrastructure is built into the upstream source already. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nevu1va@windlord.stanford.edu
Re: alternative debian/rules
On 04/25/2013 01:52 AM, Neil McGovern wrote: Perhaps you should go read the bug report first. As you seem to be unwilling to actually do research, I'll include the relevant section for your benefit: - 1: deliberate obfuscation for no benefit: echo .nr g 2 | cat - cpio.1 | \ gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1.gz Just add the extra top line to the upstream or create a patch already. then you'd have something approaching sane: cp cpio.1 debian/pax/usr/share/man/man1/paxcpio.1 gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1 Even that is two lines repeated three times (once for each manpage) instead of just dh_installman on a single line and a small .install file but that just demonstrates the insanity of the current rules. Neil Yes, that's the same thing we are talking about. Since you don't believe what I wrote, I'll state it again. I think it's silly to call the echo + cat deliberate obfuscation. It is easy to understand, and I see no problem with it. It is also not normal to say there's no benefits with such code, when clearly there is (eg: no need to patch and patch again every upstream version, as suggested...). Then, there was no reason to rush into our poor Thorsten with such aggressiveness. When you write: That cannot be guaranteed - at some point, someone else is going to need to work on pax. The build system is non-standard and not well tested because it's restricted to only two packages. If that turns out to be me, I will RM. I'm not going to spend time on the current insanity. then I don't agree, and I don't support such decision. Don't take me wrong. I do agree that using debhelper is better and that it could have been recommended to Thorsten. I do agree with the general idea to push him to use something more easy to understand and maintain by others. But *not this way*, with threats to RM his package, and calling some very easy to understand code (eg that echo + cat) as deliberate obfuscation, as if he had such bad intentions. By the way, I'm quite sure I'd find a non-debhelper style of debian/rules more easy to understand than CDBS ! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51786600.2030...@debian.org
Re: alternative debian/rules
Le Wed, Apr 24, 2013 at 01:52:36PM -0400, Neil McGovern a écrit : 1: deliberate obfuscation for no benefit: Hi everybody, Can everybody please avoid to guess or propagate guesses on other persons motivations ? I think that a discussion can not be constructive if it contains statements that look like gratuitous accusations. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424234703.gc3...@falafel.plessy.net
Re: alternative debian/rules
On Mon, Apr 22, 2013 at 11:23:51AM +0100, Jonathan Dowland wrote: On Tue, Apr 16, 2013 at 01:46:20PM -0700, Steve Langasek wrote: On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote: % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh I don't understand your point, other than to demonstrate that you're doing something which doesn't conform to policy? And running something like csh. Both seem like bad ideas! Huh? That's zsh and there was no point besides the comedic value. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423124935.GC26534@frosties
Re: alternative debian/rules
Adam Borowski kilobyte at angband.pl writes: It can be done Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. And I thought it was about freedom of choice. (I mean, I see the point, but as long as things like cdbs or the, for many people unmaintainable due to being “too magic”, dh7 style are around… it’s unfair!) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130422t113646-...@post.gmane.org
Re: alternative debian/rules
On Mon, Apr 22, 2013 at 09:38:14AM +, Thorsten Glaser wrote: Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. [citation needed] And I thought it was about freedom of choice. Linux is not about choice -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130422094547.gb14...@belkar.wrar.name
Re: alternative debian/rules
* Andrey Rahmatullin w...@wrar.name, 2013-04-22, 15:45: On Mon, Apr 22, 2013 at 09:38:14AM +, Thorsten Glaser wrote: Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. [citation needed] #690381 Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130422100922.ga7...@jwilk.net
Re: alternative debian/rules
Jakub Wilk jw...@debian.org writes: Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. Was there perhaps some emoticon missing? Uncommon debian/rules setups might be required in some cases but surely they should not be used to intentionally make it harder for other developers to understand? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84bo967tlp@sauna.l.org
Re: alternative debian/rules
On Tue, Apr 16, 2013 at 01:46:20PM -0700, Steve Langasek wrote: On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote: % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh I don't understand your point, other than to demonstrate that you're doing something which doesn't conform to policy? And running something like csh. Both seem like bad ideas! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130422102351.GA8013@debian
Re: alternative debian/rules
On Mon, Apr 22, 2013 at 09:38:14AM +, Thorsten Glaser wrote: Well yes, but if you do even small things such as generate the package manually instead of using debhelper, prepare to be shouted at by the British Cabal with threats of using superpowers to remove such packages from Debian. Please, keep jingoism off -devel. (Although perhaps the rest of us Brits should be proud that we're being cast into the same grouping as Neil and Steve, who afaict are the Brits to whom you are referring, if I've got the correct context.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130422104614.GB8013@debian
Re: alternative debian/rules
Hi, This one time, at band camp, Timo Juhani Lindfors said: Jakub Wilk jw...@debian.org writes: Thorsten, you should have kept your custom debian/rules. If it prevented incompetent developers from NMUing the package, then all good for you and for Debian. Was there perhaps some emoticon missing? Uncommon debian/rules setups might be required in some cases but surely they should not be used to intentionally make it harder for other developers to understand? No, I'm pretty sure Jakub means to be as stroppy and foolish as he sounds. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: alternative debian/rules
On Fri, Apr 05, 2013 at 10:47:39AM -0700, Russ Allbery wrote: ?? ?? pashev.i...@gmail.com writes: Indeed. So, in any case one can use its own tool just like dh: %: debian/megatool $@ Yes, from a Policy perspective. Although please consider using dh and its framework instead to make life easier for everyone else in the project who may have to help out with maintaining the package, such as the security team. It has a nice plugin module system that lets you add custom infrastructure for particular types of projects without changing the basic framework. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130416122818.GA21076@frosties
Re: alternative debian/rules
On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote: On Fri, Apr 05, 2013 at 10:47:39AM -0700, Russ Allbery wrote: ?? ?? pashev.i...@gmail.com writes: Indeed. So, in any case one can use its own tool just like dh: %: debian/megatool $@ Yes, from a Policy perspective. Although please consider using dh and its framework instead to make life easier for everyone else in the project who may have to help out with maintaining the package, such as the security team. It has a nice plugin module system that lets you add custom infrastructure for particular types of projects without changing the basic framework. % ls -lh debian/rules lrwxrwxrwx 1 mrvn users 1 Apr 16 12:27 debian/rules - /usr/bin/dh I don't understand your point, other than to demonstrate that you're doing something which doesn't conform to policy? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
alternative debian/rules
I've just realized that debian/rules might not be a makefile, but can be a script in any language. Is there any package using debian/rules whihc is not a makefile? Are there any packages that can get advantages by using debian/rules written in bash/perl/python/etc? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8zdme0i22qwgjxjrbstqxehk03zgcr+xb+6d5z59n9...@mail.gmail.com
Re: alternative debian/rules
Hallo Игорь Пашев, 2013-04-05 um 13:32:24 schriebst Du: I've just realized that debian/rules might not be a makefile, but can be a script in any language. Is there any package using debian/rules whihc is not a makefile? Are there any packages that can get advantages by using debian/rules written in bash/perl/python/etc? See http://bugs.debian.org/636016 ;-) Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: alternative debian/rules
On 05/04/13 12:32, Игорь Пашев wrote: I've just realized that debian/rules might not be a makefile, but can be a script in any language. This is technically possible (dpkg allows it), but not acceptable for Debian packages (Debian Policy requires that debian/rules is an executable makefile). Is there any package using debian/rules whihc is not a makefile? There have been a few in the past. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515eb848.7050...@debian.org
Re: alternative debian/rules
On Fri, Apr 05, 2013 at 03:32:24PM +0400, Игорь Пашев wrote: I've just realized that debian/rules might not be a makefile, but can be a script in any language. The policy says: # 4.9. Main building script: `debian/rules' # - # # This file must be an executable makefile, and contains the # package-specific recipes for compiling the package and building binary # package(s) from the source. Is there any package using debian/rules which is not a makefile? Are there any packages that can get advantages by using debian/rules written in bash/perl/python/etc? Because of the following requirement, it's not that easy. It can be done, here's an example how to use a JIT C compiler (tcc) this way: dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc although you might have trouble smuggling this through the FTPmasters :p On the other hand, one of fresh DDs already thanked me for this example, so be afraid. Be very afraid. Hope this helps :) -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405114149.ga7...@angband.pl
Re: alternative debian/rules
Hi, On Fri, Apr 05, 2013 at 03:32:24PM +0400, Игорь Пашев wrote: I've just realized that debian/rules might not be a makefile, but can be a script in any language. Not really. http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules This file must be an executable makefile, [...] That it might work with something else might be, but that's not allowed anyway. Regards, Rene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405114016.gf...@rene-engelhard.de
Re: alternative debian/rules
Le vendredi 5 avril 2013 13:41:50, Adam Borowski a écrit : It can be done, here's an example how to use a JIT C compiler (tcc) this way: dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc although you might have trouble smuggling this through the FTPmasters :p On the other hand, one of fresh DDs already thanked me for this example, so be afraid. Be very afraid. I'd be scared if it was uploaded to Debian but as the maintainer of tcc I'm quite amused and happy to see people use it to do crazy stuff. Hope this helps :) Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: alternative debian/rules
2013/4/5 Adam Borowski kilob...@angband.pl: The policy says Indeed. So, in any case one can use its own tool just like dh: %: debian/megatool $@ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8z603EAhb86khzjAfOY1XvO42A+Li_V5mrjUx=w+uq...@mail.gmail.com
Re: alternative debian/rules
Игорь Пашев pashev.i...@gmail.com writes: Indeed. So, in any case one can use its own tool just like dh: %: debian/megatool $@ Yes, from a Policy perspective. Although please consider using dh and its framework instead to make life easier for everyone else in the project who may have to help out with maintaining the package, such as the security team. It has a nice plugin module system that lets you add custom infrastructure for particular types of projects without changing the basic framework. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ioc1j8@windlord.stanford.edu
