FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CRUX > CRUX

 
 
LinkBack Thread Tools
 
Old 08-17-2010, 10:38 AM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

Hi folks,


I've written down several rules which upstream packages (IMHO)
should comply to make distro maintainer's life much easier.
(especially when it comes to things like crosscompiling)

http://www.metux.de/index.php/de/component/content/article/57.html

I'd like to hear your oppinions about it.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 09-13-2010, 02:54 AM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

Hi folks,


I've written a bunch of rules which upstreams should follow to make
distro maintainer's life much easier. Feel free to comment on it.

http://www.metux.de/index.php/de/component/content/article/57.html


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
CRUX mailing list
CRUX@lists.crux.nu
http://lists.crux.nu/mailman/listinfo/crux
 
Old 09-16-2010, 08:35 AM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

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
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C91D6DF.9070508@metux.de">http://lists.debian.org/4C91D6DF.9070508@metux.de
 
Old 09-16-2010, 08:40 AM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

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
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C91D7FE.5030405@metux.de">http://lists.debian.org/4C91D7FE.5030405@metux.de
 
Old 09-16-2010, 09:00 AM
Vincent Bernat
 
Default RFC: Rules for distro-friendly packages

On Thu, 16 Sep 2010 10:40:30 +0200, Enrico Weigelt <weigelt@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 autoconf stuff:
- Why require autogen.sh? On a release, configure script should be
present. No need to rebuild it. Some users just don't have recent enough
autotools to rebuild the configure. Moreover, with modern autotools, I tend
to think that autoreconf -i is just as simple as autogen.sh.
- Why require building in a separate tree? Why it helps, most of the
packages we have just build in the same source tree.
- Not using AC_TRY_RUN is too strong. This macro has a parameter to be
used when cross-compiling. It is more useful to detect a problem when not
cross-compiling with AC_TRY_RUN than to not detect it at all.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 0668dd331505dad9896cff083909ae7d@chopper.luffy.cx" >http://lists.debian.org/0668dd331505dad9896cff083909ae7d@chopper.luffy.cx
 
Old 09-16-2010, 10:28 AM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

* Vincent Bernat <bernat@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 configure.in+friends).
And you don't seriously want to patch autogenerated files, do you ? ;-o

> 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.

> Moreover, with modern autotools, I tend
> to think that autoreconf -i is just as simple as autogen.sh.

That might be true for most packages, but some also need other stuff.
Therefore calling autogen.sh script is the more generic interface.
And that's one of the point it's about: make the interface between
package and distro build system as simple as possible.

> - Why require building in a separate tree? Why it helps, most of the
> packages we have just build in the same source tree.

That shows up a lot of possible errors with autogenerated files.

> - Not using AC_TRY_RUN is too strong.

No, it's mandatory. It simply cannot crosscompile, no chance.

> This macro has a parameter to be used when cross-compiling.

It's inherently unreliable, by design. The developer has to specify
some default behaviour in case of crosscompiling. And that's most
likely wrong. If you do use that macro, you've normally relying
on basicly assumptions. Such as the building system is equal
(yes *equal*, not just similar) to the actual target system.

> It is more useful to detect a problem when not cross-compiling
> with AC_TRY_RUN than to not detect it at all.

If you really wanna have some runtime tests, then it should be
done separately (eg. separate script or in make test stage).


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100916102857.GA2492@nibiru.local">http://lists.debian.org/20100916102857.GA2492@nibiru.local
 
Old 09-16-2010, 10:44 AM
Luca Bruno
 
Default RFC: Rules for distro-friendly packages

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.S. | lucab (AT) debian.org
`. `'` | GPG Key ID: 3BFB9FB3
`- http://www.debian.org | Debian GNU/Linux Developer
 
Old 09-16-2010, 12:38 PM
Enrico Weigelt
 
Default RFC: Rules for distro-friendly packages

* Luca Bruno <lucab@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 contain the most of it.
One thing I yet missed was configurable install pathes.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100916123811.GA4165@nibiru.local">http://lists.debian.org/20100916123811.GA4165@nibiru.local
 
Old 09-16-2010, 10:58 PM
Russ Allbery
 
Default RFC: Rules for distro-friendly packages

Enrico Weigelt <weigelt@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 come in multiple tarballs.
Now that our source format can handle that, I think that prohibition is a
bit too strong, although it's still less convenient.

The test suites for my packages do network communication on localhost.
It's completely impossible to test a lot of network code if you don't
allow this. But your build system point currently says that's not
allowed. I think you should allow localhost network communication for the
test suite (although not the main package build).

The way that the point about build output not varying based on the runtime
properties of the building system is both confusingly stated (by "build
output" I would have assumed you meant the textual output from the
compiler to the screen, not the constructed binaries) and I think way too
restrictive. You're basically saying that people aren't allowed to use
the typical Autoconf semantics of honoring --with and --without flags and
autodetecting an optional dependency if neither is given, but that's best
practice. Instead, I think you should say that it must be possible to
pass flags into the build system such that the build will always either
produce the same binaries or will fail, not silently drop features that
have been explicitly requested (or silently add features that have been
explicitly disabled).

I disagree with requiring static libraries even with the exception that
you list. In this day and age, I think static libraries are basically
useless unless one can not yet commit to a stable ABI, and there are
various situations (such as support for dynamic plugins) where supporting
them is a huge pain.

Libraries should NOT build shared libraries if they can't commit to a
stable ABI with proper SONAME changes when it changes. Yes, that sucks,
and there should be a stable ABI, but if there isn't, static-only is
better than an unstable shared library ABI not reflected in SONAME
changes.

I think you should specifically call out DESTDIR as the mechanism that
should be supported for specifying the installation location even if
Autoconf is not used. Everything else is more annoying to use, and
supporting DESTDIR with hand-written Makefiles is not that hard.

I strongly disagree with requiring pkg-config. None of my libraries
support this, and I don't see any point in using pkg-config if the way
that one uses the shared library is to just add -l<library-name>. You
don't need pkg-config to figure that out. It's a nice-to-have if upstream
wants to bother, but is absolutely not required.

I absolutely refuse to call my autogen script autogen.sh for the same
reason that I oppose putting language extensions on any executable. Linux
is not Windows; we don't need to call things foo.bat and bar.exe.

My packages will not be using pkg-config when pkg-config doesn't do
anything useful or when I can reproduce its results in more supportable
ways. The pkg-config Autoconf glue is ugly and does not properly
implement Autoconf semantics (for example, it incorrectly merges CPPFLAGS
and CFLAGS, and LIBS and LDFLAGS, and is not written using modern Autoconf
features and style), and is not something I'm willing to use or support
unless I absolutely have to.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878w31fg8a.fsf@windlord.stanford.edu">http://lists.debian.org/878w31fg8a.fsf@windlord.stanford.edu
 
Old 09-17-2010, 02:00 AM
Paul Wise
 
Default RFC: Rules for distro-friendly packages

On Thu, Sep 16, 2010 at 6:44 PM, Luca Bruno <lucab@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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinWXm9Vs6jcn5O+KL4BH11Kdv2kyWc4T99P6f4x@mail .gmail.com">http://lists.debian.org/AANLkTinWXm9Vs6jcn5O+KL4BH11Kdv2kyWc4T99P6f4x@mail .gmail.com
 

Thread Tools




All times are GMT. The time now is 06:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org