* Tollef Fog Heen tfh...@err.no schrieb:
Hi,
If they don't work, and we don't ship the needed auto* versions, we're
effectively distributing sourceless software, which is quite
problematic.
In this case, the source is broken and should be fixed.
cu
--
* Adam Borowski kilob...@angband.pl schrieb:
A monstrual sh script that's generated using all unsightly tricks that were
necessary for 70's shells is as far from being source as you can get and
still be a text file.
ACK. A small shell script using a bunch of well-designed functions
(which
* Adam Borowski kilob...@angband.pl schrieb:
* non-distro users -- another issue to watch for while hacking on the
program. As long as they don't modify the autotoolage, they
don't need autotools installed -- and if they did, they do want
to be told what they
* Russ Allbery r...@debian.org schrieb:
This and some of the other things that I said about pkg-config on this
thread were way too strong, and I want to generally apologize to the
mailing list readers and specifically to all the people who have been
working on pkg-config. I got defensive and
* Yavor Doganov ya...@gnu.org schrieb:
That's exactly where --with-zlib and --with-libbz2 should be used
(according to the practice recommended by Autoconf, at least).
--enable-compression could by default check for zlib and libbz2, and
enable either or both if found. If neither is found and
Enrico Weigelt wrote:
* Yavor Doganov ya...@gnu.org schrieb:
Switching dependencies which silently enables/disables features is
a generally bad approach.
Well, in my very humble experience, an optional dependency is there
precisely to provide an optional feature.
No, opposite
* Bernhard R. Link brl...@debian.org schrieb:
The sysadmins should run the build through a dedicated build system
which generates packages for their target(s).
A dedicated build system is always stricly inferior for a user. It needs
more efford to set it up, efford to get all the build
Russ Allbery r...@debian.org writes:
[...]
No. I don't believe it's very important or at all necessary, and since
I don't use pkg-config myself and don't plan to start, it's not
particularly important. While I'll probably do something about it
eventually when I have some free time, it's
Le jeudi 16 septembre 2010 à 10:40 +0200, Enrico Weigelt a écrit :
Hi folks,
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
http://www.metux.de/index.php/de/component/content/article/57.html
Free feel to comment on it :)
As
On Sun, Sep 19, 2010 at 10:08:47AM +0200, Josselin Mouette wrote:
As for automake, you should strongly recommend AM_MAINTAINER_MODE.
Packages without this macro are a real pain to patch.
If upstream wants maintainer mode by default (as you have without the
macro set), they just need to set
Le dimanche 19 septembre 2010 à 10:43 +0200, Adam Borowski a écrit :
Uhm, no. AM_MAINTAINER_MODE is bad for:
* upstream -- it forces manual rebuilds
* non-distro users -- another issue to watch for while hacking on the
program. As long as they don't modify the autotoolage, they
* Adam Borowski kilob...@angband.pl [100919 10:43]:
Uhm, no. AM_MAINTAINER_MODE is bad for:
* upstream -- it forces manual rebuilds
I do not understand this.
* non-distro users -- another issue to watch for while hacking on the
program. As long as they don't modify the
]] Bernhard R. Link
| * Debian -- building things from the actual source is one of the core rules
|
| Especially for Debian maintainer mode is a big win. While it's nice if
| the maintainer regulary checks that those files still work with the
| current tools and submitts patches to upstream if
On Sun, Sep 19, 2010 at 02:07:10PM +0200, Josselin Mouette wrote:
The only benefit that AM_MAINTAINER_MODE can bring is cleaner deb diffs,
which can be obtained just as well by removing the modified generated files
in debian/rules clean.
In fact, it would be nice to have a lintian check
Le dimanche 19 septembre 2010 à 16:47 +0200, Adam Borowski a écrit :
On Sun, Sep 19, 2010 at 02:07:10PM +0200, Josselin Mouette wrote:
You must be mistaken by automake’s counter-intuitiveness.
The infamous maintainer mode *is the default* when you don’t set the
macro. Setting
On Sun, Sep 19, 2010 at 05:35:03PM +0200, Josselin Mouette wrote:
Le dimanche 19 septembre 2010 à 16:47 +0200, Adam Borowski a écrit :
The infamous maintainer mode *is the default* when you don’t set the
macro.
You need to either remove AM_MAINTAINER_MODE from configure.ac or
* Ian Jackson ijack...@chiark.greenend.org.uk schrieb:
Enrico Weigelt writes (RFC: Rules for distro-friendly packages ):
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
Thanks for doing this. But I have to say that the tone of your
* Yavor Doganov ya...@gnu.org schrieb:
Switching dependencies which silently enables/disables features is
a generally bad approach.
Well, in my very humble experience, an optional dependency is there
precisely to provide an optional feature.
No, opposite direction: features are
* Enrico Weigelt weig...@metux.de [100918 09:24]:
* Yavor Doganov ya...@gnu.org schrieb:
Switching dependencies which silently enables/disables features is
a generally bad approach.
Well, in my very humble experience, an optional dependency is ther
precisely to provide an optional
* Bernhard R. Link brl...@debian.org schrieb:
Well, I doubt one of those POVs is more valid than the other. While
features are an interesting point, the user is often more interested
in how do I get this to work with the maximum of functionality it
can provide given what I have or can
Vincent Bernat writes (Re: RFC: Rules for distro-friendly packages):
I am not a native English speaker so I fail to see how saying living in
a narrow-minded world is rude.
I see. I hope I can help by explaining that calling someone
narrow-minded is insulting. Telling someone they are living
Enrico Weigelt writes (Re: RFC: Rules for distro-friendly packages):
Ian Jackson ijack...@chiark.greenend.org.uk schrieb:
We aren't in a position to dictate to upstream.
No, we aren't. But we (as downstreams) can define rules on what we
consider a good package engineering - if upstream
* Enrico Weigelt weig...@metux.de [100918 05:49]:
* Jesús M. Navarro jesus.nava...@undominio.net schrieb:
Think of the most probable environment where somebody goes with the hassle
of compiling new package into old RHEL 2. Do you think such a chore is
taken out of fun? Or is it an
On Fri, 17 Sep 2010, Vincent Bernat wrote:
I am not a native English speaker so I fail to see how saying
living in a narrow-minded world is rude. Wiktionary does not say
that narrow-minded is rude. It says having restricted or rigid
views which is exactly what I am expressing here. I should
* Ian Jackson ijack...@chiark.greenend.org.uk schrieb:
Rules is just wrong. Guidelines might be appropriate, but I would
suggest Recommendations.
In my case it are rules, which are required to get an qm stamp in
my company. Actually, it's just the tip of an iceberg of processes,
I can't
* Enrico Weigelt weig...@metux.de schrieb:
They don't need to. OSS-QM provides canonical repositories [2],
where everybody can fetch from easily (especially built for
automated systems). Debian changesets are also imported automatically.
(as far as possible)
[2]
OoO Pendant le temps de midi du jeudi 16 septembre 2010, vers 12:28,
Enrico Weigelt weig...@metux.de disait :
About autoconf stuff:
- Why require autogen.sh? On a release, configure script should be
present. No need to rebuild it.
No, there often *is* a need to rebuild it (actually,
* Vincent Bernat ber...@debian.org schrieb:
Some users just don't have recent enough autotools to rebuild the
configure.
They should simply install it. Similar as they need recent toolchain,
make, pkg-config, etc, etc.
No, no, no. Users are not limited to Debian developers using
OoO En cette matinée ensoleillée du vendredi 17 septembre 2010, vers
09:08, Enrico Weigelt weig...@metux.de disait :
No, no, no. Users are not limited to Debian developers using Sid. Users
may try to compile on an old RHEL 2.
In this case they should really *know* what they're doing.
* Russ Allbery r...@debian.org schrieb:
Enrico Weigelt weig...@metux.de writes:
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
http://www.metux.de/index.php/de/component/content/article/57.html
Free feel to comment on it :)
* Vincent Bernat ber...@debian.org schrieb:
Wait a minute! Arbitrary _users_ should never try to rebuild anything
on a stable/production system. As soon as you're attempting that,
you're stepping into the package maintainer or developer role, and
then you should *know* what you're doing
On 17.09.10 10:59, Enrico Weigelt wrote:
* Vincent Bernatber...@debian.org schrieb:
Wait a minute! Arbitrary _users_ should never try to rebuild anything
on a stable/production system. As soon as you're attempting that,
you're stepping into the package maintainer or developer role, and
then
Enrico Weigelt writes (RFC: Rules for distro-friendly packages ):
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
Thanks for doing this. But I have to say that the tone of your
document isn't really appropriate for the social context
Vincent Bernat writes (Re: RFC: Rules for distro-friendly packages):
We just don't live in the same world. Keep living in your narrow-minded
world where users are not allowed to compile themselves software and
where all systems are up-to-date. In my real world, I have users
Hi, Enrico:
On Friday 17 September 2010 09:08:39 Enrico Weigelt wrote:
* Vincent Bernat ber...@debian.org schrieb:
Some users just don't have recent enough autotools to rebuild the
configure.
They should simply install it. Similar as they need recent toolchain,
make, pkg-config,
Enrico Weigelt weig...@metux.de writes:
* Russ Allbery r...@debian.org schrieb:
You've prohibited upstream distributions that come in multiple tarballs.
With that I mean that you don't need to unpack multiple tarballs to
get a working tree (Xorg/Xf86 was such a case, several years ago).
OoO Pendant le temps de midi du vendredi 17 septembre 2010, vers 12:16,
Ian Jackson ijack...@chiark.greenend.org.uk disait :
We just don't live in the same world. Keep living in your narrow-minded
world where users are not allowed to compile themselves software and
where all systems are
Enrico Weigelt wrote:
* Russ Allbery r...@debian.org schrieb:
You're basically saying that people aren't allowed to use
the typical Autoconf semantics of honoring --with and --without
They should use --enable-*/--disable-* flags for switching features.
--with and --enable have different
* Russ Allbery r...@debian.org schrieb:
Hi,
With that I mean that you don't need to unpack multiple tarballs to
get a working tree (Xorg/Xf86 was such a case, several years ago).
Right. And I'm saying now that our packaging tools can handle that case,
it's not clear to me why Debian
* Giacomo A. Catenazzi c...@cateee.net schrieb:
On 17.09.10 10:59, Enrico Weigelt wrote:
* Vincent Bernatber...@debian.org schrieb:
Wait a minute! Arbitrary _users_ should never try to rebuild anything
on a stable/production system. As soon as you're attempting that,
you're stepping into
Enrico Weigelt weig...@metux.de writes:
* Russ Allbery r...@debian.org schrieb:
--enable/--disable is for internal features. --with/--without is for
features that depend on external packages. See the Autoconf
documentation.
This distinction is IMHO a wrong concept, that maybe gets more
* Jesús M. Navarro jesus.nava...@undominio.net schrieb:
Think of the most probable environment where somebody goes with the hassle
of compiling new package into old RHEL 2. Do you think such a chore is
taken out of fun? Or is it an environment where an overworked sysadmin at
charge of a
Hi folks,
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
http://www.metux.de/index.php/de/component/content/article/57.html
Free feel to comment on it :)
cu
--
--
On Thu, 16 Sep 2010 10:40:30 +0200, Enrico Weigelt weig...@metux.de
wrote:
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
http://www.metux.de/index.php/de/component/content/article/57.html
Free feel to comment on it :)
About
* Vincent Bernat ber...@luffy.cx schrieb:
Hi,
About autoconf stuff:
- Why require autogen.sh? On a release, configure script should be
present. No need to rebuild it.
No, there often *is* a need to rebuild it (actually, much of my
QM work on dozens packages requires changing
Enrico Weigelt scrisse:
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
You may also be interested in http://wiki.debian.org/UpstreamGuide
Cheers, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal
* Luca Bruno lu...@debian.org schrieb:
Enrico Weigelt scrisse:
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
You may also be interested in http://wiki.debian.org/UpstreamGuide
Thanks.
It's seems my rules are a bit more rigid and
Enrico Weigelt weig...@metux.de writes:
I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:
http://www.metux.de/index.php/de/component/content/article/57.html
Free feel to comment on it :)
You've prohibited upstream distributions that
On Thu, Sep 16, 2010 at 6:44 PM, Luca Bruno lu...@debian.org wrote:
You may also be interested in http://wiki.debian.org/UpstreamGuide
Just added a link to Enrico's page from that.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to
49 matches
Mail list logo
