* Yavor Doganov 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
> --enabl
* Russ Allbery 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 annoyed for
* Adam Borowski 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 need instead of
* Adam Borowski 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 might also come from
* Tollef Fog Heen 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
--
---
Enrico Weigelt wrote:
> * Yavor Doganov 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 dir
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 o
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 AM
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
]] "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
* Adam Borowski [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 autotoolage, they
>
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, the
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 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 :
Russ Allbery 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 very low on my
* Bernhard R. Link 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 dependencies
* Enrico Weigelt 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] http://www.metux.de/download/oss-qm/norma
* Ian Jackson 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 describe in detail right now.
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 sh
* Enrico Weigelt [100918 05:49]:
> * Jesús M. Navarro 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
Enrico Weigelt writes ("Re: RFC: Rules for distro-friendly packages"):
> Ian Jackson 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 -
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.
* Bernhard R. Link 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 reasonably get". Fro
* Enrico Weigelt [100918 09:24]:
> * Yavor Doganov 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 feature.
>
> No, o
* Yavor Doganov 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 functional requi
* Ian Jackson 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
> document isn't really
* Jesús M. Navarro 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 lot of disparaged mach
Enrico Weigelt writes:
> * Russ Allbery 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 obvious
> when internal fe
* Giacomo A. Catenazzi schrieb:
> On 17.09.10 10:59, Enrico Weigelt wrote:
> >* Vincent Bernat 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 maint
* Russ Allbery 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 should be t
Enrico Weigelt wrote:
> * Russ Allbery 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 semantics, a
OoO Pendant le temps de midi du vendredi 17 septembre 2010, vers 12:16,
Ian Jackson 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 up-to-date. In my real w
Enrico Weigelt writes:
> * Russ Allbery 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).
Right. And I'm saying now th
Hi, Enrico:
On Friday 17 September 2010 09:08:39 Enrico Weigelt wrote:
> * Vincent Bernat 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, e
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 w
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.
On 17.09.10 10:59, Enrico Weigelt wrote:
* Vincent Bernat 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* w
* Vincent Bernat 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 (or at leas
* Russ Allbery schrieb:
> Enrico Weigelt 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
OoO En cette matinée ensoleillée du vendredi 17 septembre 2010, vers
09:08, Enrico Weigelt 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.
> RHEL is mea
* Vincent Bernat 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 Sid. Us
OoO Pendant le temps de midi du jeudi 16 septembre 2010, vers 12:28,
Enrico Weigelt 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, much of my
>
On Thu, Sep 16, 2010 at 6:44 PM, Luca Bruno 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 debian-devel-requ...@lists.debian.org
with a subjec
Enrico Weigelt 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 come in multiple
* Luca Bruno 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 contain
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 O
* Vincent Bernat 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 configure.in+friends).
And
On Thu, 16 Sep 2010 10:40:30 +0200, Enrico Weigelt
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 autoconf stuff:
48 matches
Mail list logo
