Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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. Users
> may try to compile  on an old RHEL 2. 

In this case they should really *know* what they're doing.
RHEL is meant as an binary-only distribution - you should NOT install
arbitrary packages without going through the whole distro's build
engine and qm process, otherwise they'll risk merly all the stability
ensured by the distro - that's a design aspect of those distros.

On the other hand, there are often cases where you *NEED* to rebuild
the whole configure stuff.

> They should  absolutely not try to rebuild configure since it is likely
> to not work and leave them with an unconfigurable package. 

Why that, exactly ?

> On most projects, there is not autogen/bootstrap in the realeases for
> this very reason: do not confuse the user and let him install autotools
> which is not mandatory  at all. autogen/bootstrap
> is shipped in the VCS repository because this is targeted at developer.

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 least learn it).

> autotools are  aimed at the end  user, not the distro  packager. This is
> stated in the  introduction to autotools.  This is nice  to be nice with
> the distro packager but the primary  target is the lambda user (which is
> usually less skilled than the distro packager).

That's one of the fundamental conceptional flaws.
 
> Compiling software from source is  enough a pain to avoid any unecessary
> dependency.

Compiling software is task for developers or package maintainers.
Users should use the finished packages provided by their distro.

Again: we're talking about production systems here.

> Oh sure, if there  is a problem that can only be  detected at runtime, I
> will let  the user  deal with it  in some  "make test" that  nobody runs

That's why he should use distro's packages.

> instead  of  handling  the  problem   for  him  in  most  situations  in
> configure. 

That bit of convenience for the specific (and nowadays relatively rare)
case that somebody just wants to compile and install some package from
upstream source, for **EXACTLY** the same system it will be running on,
overweights the hell of trouble for all the distro maintainers ?

On a QM perspective, guessing something about the target system from the
_running_ system is an absolute NO GO. The whole idea is inherently flawed.

> Again, configure is targetted  at the end user (which usually
> does not cross-compile). It  should automatically configure the software
> to  be in  a workable  state  after compilation.

And that's what it does NOT solve. AC_TRY_RUN+friends guess wrong, 
as soon as the building system is not equal to the actual target.

> No need  to read  some README or run some additional scripts.

Just design the software that it does the necessary checks at runtime,
if there *really* is something that cannot be found out with toolchain-
only based tests (which are NOT executing any code compiled for the target).

> As upstream, I  care about Debian and cross-compiling  but I also should
> care about  people wanting to  compile my software  on old RHEL 2  or on
> Debian Etch (an  old enough platform to require some  runtime test in my
> case). None of those platforms have a recent enough autotools to rebuild
> configure, BTW.

Then they should be updated.


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

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


-- 
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/20100917070839.ga23...@nibiru.local

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

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 meant as an binary-only distribution - you should NOT install
> arbitrary packages without going through the whole distro's build
> engine and qm process, otherwise they'll risk merly all the stability
> ensured by the distro - that's a design aspect of those distros.
[...]

> 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 least learn it).
[...]

Hello, /usr/local...

>> As upstream, I  care about Debian and cross-compiling  but I also should
>> care about  people wanting to  compile my software  on old RHEL 2  or on
>> Debian Etch (an  old enough platform to require some  runtime test in my
>> case). None of those platforms have a recent enough autotools to rebuild
>> configure, BTW.

> Then they should be updated.

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 that
are running  very old  distro and that  cannot upgrade it  nightly while
everything  works perfectly  ans just  need to  test the  software  on a
preprod system before trying to package it.
-- 
BOFH excuse #148:
Insert coin for new game


pgp5cnptLYLXQ.pgp
Description: PGP signature

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

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

Ofcourse you can provide multiple different tarballs or different
compressions.

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

Runtime test suites are different thing. I'm talking about the build process.
What I want to prohibit is such cases where you start the build and it
now starts some downloads or queries some servers, etc, all that risks
making the build indeterministic and thus unreliable.
 
> 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.

With build output I mean the compiled files (binaries, etc) - not the
logs, of course. The problem is that certain packages look for runtime
properties like availble memory, availability of certain devices, etc,
and suddenly produce different code.

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

They should use --enable-*/--disable-* flags for switching features.
Switching dependencies which silently enables/disables features is
a generally bad approach. Instead have feature switches and maybe
tell what these features depend on.

> 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 

Building static libraries (additional to shared/dynamic ones) usally
is not a big task. And still many people need them.

> one can not yet commit to a stable ABI, and there are

Why that exactly ?

> various situations (such as support for dynamic plugins) where supporting
> them is a huge pain.

In very most cases, that's bad design.

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

Changing ABI simply *has* to be reflected in the soname. Period.
If some lib doesnt do that, it simply fails the test. Perhaps rude,
but necessary to ensure quality.

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

Yes, but that's a build system speficic issue and so will be stated
in the appropriate sections (yes, the text is not finished yet).

> I strongly disagree with requiring pkg-config.  

Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.

> None of my libraries support this,

Bad. You should fix 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.  

Because that doesn't always suffice. It requires that the library
is in the toolchain's standard search path. And what about cflags ?
What about dependencies ?

> You don't need pkg-config to figure that out. 

No, but it makes it *MUCH* easier.

> It's a nice-to-have if upstream wants to bother, but is absolutely
> not required.

For my setups, it *is* 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.

It could have been named "wurstbrot" or whatever, but fact is, most
packages name it that way and so it's an de-facto standard. And 
standardization is one of the major aspects of these rules.

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

Then you'll have to live with the fact, that other people won't
like your libraries very much, for that reason.

> The pkg-config Autoconf glue is ugly and does not properly implement
> Autoconf semantics (for example, it incorrectly merges CPPFLAGS and
> CFLAGS, an

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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 least learn it).
> [...]
> 
> Hello, /usr/local...

Should never be used.

> > Then they should be updated.
> 
> We just don't live in the  same world. 

Maybe.

> Keep living in your narrow-minded world where users are not allowed
> to compile themselves software and where all systems are up-to-date.

I never said this. I dont want to forbid them anything. But as soon
as you're beginning to compile and install packages on yourself,
you're leaving the user role, and you should know what you're doing.
(or do it on some safe playgound).

> In my real world, I have users that are running very old distro and
> that cannot upgrade it nightly while everything works perfectly 
> ans just need to test the software on a preprod system before
> trying to package it.

These users should know what they're doing, or learn it, or call
someone who knows it. Otherwise they run into great chance to
shoot down their own systems.


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

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


-- 
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/20100917085934.gc23...@nibiru.local

Re: RFC: Rules for distro-friendly packages

[Giacomo A. Catenazzi]

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* what you're doing (or at least learn it).

[...]

Hello, /usr/local...


Should never be used.


no?



Keep living in your narrow-minded world where users are not allowed
to compile themselves software and where all systems are up-to-date.


I never said this. I dont want to forbid them anything. But as soon
as you're beginning to compile and install packages on yourself,
you're leaving the user role, and you should know what you're doing.
(or do it on some safe playgound).


I think you are confusing the word "users". For a distribution in
"users" we include normal users (of a multiuser system), sysadmin,
super users, programmers, and any person that install they own machine.

Many of such roles requires to compile and install customs programs.
Linux always supported such behaviour.

You know, gcc is installed in debian not only for debian developers,
and surelly not for only for programmers that will not use/test they
own programs.



ciao
cate


--
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/4c9335d4.3040...@cateee.net

Re: RFC: Rules for distro-friendly packages

[Ian Jackson]

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.  It reads
very much like a series of demands and instructions.

We aren't in a position to dictate to upstream.  Upstream can do what
they want, and what we should be doing is offering friendly advice
along with explanations.

As it is, I'm afraid, I think your document does more harm than good.
The wiki page (http://wiki.debian.org/UpstreamGuide) is much better.

Sorry to be discouraging.

Ian.


-- 
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/19603.16265.659171.342...@chiark.greenend.org.uk

Re: RFC: Rules for distro-friendly packages

[Ian Jackson]

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 that
> are running  very old  distro and that  cannot upgrade it  nightly while
> everything  works perfectly  ans just  need to  test the  software  on a
> preprod system before trying to package it.

I agree with your underlying point.  But there is absolutely no call
for phrases like "keep living in your narrow-minded world".  I think
you owe Enrico an apology.

Please try to keep this list polite.  It is OK to disagree with
people.  It is not OK to call them rude names.

Thanks,
Ian.


-- 
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/19603.16409.242049.662...@chiark.greenend.org.uk

Re: RFC: Rules for distro-friendly packages

[Jesús M. Navarro]

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, etc, etc.
> >
> > 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 meant as an binary-only distribution - you should NOT install
> arbitrary packages without going through the whole distro's build
> engine and qm process, otherwise they'll risk merly all the stability
> ensured by the distro - that's a design aspect of those distros.

Wrong.  RHEL is *a* Linux distribution.  A comoditization of well known 
practices in order to make sysadmin lifes easier (with its own share of 
idiosyncrasies) that pre-dates by long, long time those distributions and 
that, basically, have settled into the `./configure && make && make install` 
paradigm.

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 machines is put into that need because out of 
his reach constrains?  RHEL is a fine environment; Debian is even better but 
forcing a busy sysadmin to intimately know about all the fine and gory 
details of Debian, Red Hat, Solaris, HP-Ux and AIX, just to name a few, not 
out of his own convenience and without the strongest need is not only a hard 
proposition but it is unrealistic.

>
> On the other hand, there are often cases where you *NEED* to rebuild
> the whole configure stuff.

Truly.  As there are cases when I have to go through the Makefile or even the 
source code to patch them so they run in my systems. But, please, do not make 
those cases more usual that *strictly* needed.

> > They should  absolutely not try to rebuild configure since it is likely
> > to not work and leave them with an unconfigurable package.
>
> Why that, exactly ?

Because as much as any other software, autotools tend not to be forwards 
compatible: as long as you use a feature from x+7.y.z it will probably fail 
when runing older x.y.z.

> > On most projects, there is not autogen/bootstrap in the realeases for
> > this very reason: do not confuse the user and let him install autotools
> > which is not mandatory  at all. autogen/bootstrap
> > is shipped in the VCS repository because this is targeted at developer.

Quite true.

> Wait a minute! Arbitrary _users_ should never try to rebuild anything
> on a stable/production system.

You seem to forget that in the context of this discussion "arbitrary users" 
are sysadmins on their duty.  They are perfectly expected to be recompiling 
software on stable/production systems.  Heck, it's even there, on the FHS:

'/usr/local': The /usr/local hierarchy is for use by the system administrator 
when installing software locally.
'/usr/src': Source code may be place placed in this subdirectory, only for 
reference purposes.

Pre-compiled software is a darely and these-days-very-common convenience that 
any sysadmin will take advantage of if at all possible but don't forget that 
*the* distribution format is the source tarball.

> 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 least learn it).

Ah... those youngsters... package maintainers are a very convenient and most 
praised *proxies* for the work of the sysadmin.  Of course a sysadmin has to 
know his trade but, please, do not multiplicate idiosyncrasies for the sake 
of it nor make conveniences into obstacles when not strongly needed.  Of 
course "proper packages" are "better" but in many situations a make install 
onto /usr/local is good enough and "better" may change its meaning when 
dealing with half a dozen different unix-like systems.

> > autotools are  aimed at the end  user, not the distro  packager. This is
> > stated in the  introduction to autotools.  This is nice  to be nice with
> > the distro packager but the primary  target is the lambda user (which is
> > usually less skilled than the distro packager).
>
> That's one of the fundamental conceptional flaws.

It might be the case, but then it's a "fundamental conceptional flaw" from the 
very developers of the tool.  It's usually not too wise to go against the 
producer conceptions.

> > Compiling software from source is  enough a pain to avoid any unecessary
> > dependency.
>
> Compiling software is task for developers or package maintainers.

It's not.  Compiling software is a task for sysadmins too.

> Users should use the finished packages provided by their distro.

As long as possible.

> Again: we're talking about production systems here.

Re: Moving package with quilt to new upstream version

[Raphael Hertzog]

On Wed, 15 Sep 2010, Henrique de Moraes Holschuh wrote:
> On Wed, 15 Sep 2010, Goswin von Brederlow wrote:
> >   QUILT_PATCHES=debian/patches quilt push
> > 
> > will do the same. You only need QUILT_PATCHES for the first quilt call.
> 
> Is that so?  That would be good news, but it doesn't match my
> experience...  although the last time I tried that was some months ago.
> Is it new functionality in quilt, or something changed in the way dpkg
> sets up .pc/ recently ?

Both: dpkg-source creates the .pc with the appropriate info, and quilt has
been modidied (with upstream collaboration) to use that info (and set it
up if it's not there).

And for you problem of dirty VCS, do you know of --unapply-patches option
for dpkg-source? you can put it in debian/source/local-options, see
dpkg-source(1) for explanations.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20100917120750.gc13...@rivendell.home.ouaza.com

plz add my id for link exchang.........

[master seo]

hi...


 Thanks... for  link   exchang.

Bug#597196: ITP: neuron -- simulation environment for computational models of (networks of ) neurons

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: NeuroDebian Team 


* Package name: neuron
  Version : 7.2
  Upstream Author : Michael Hines  and others
* URL : http://www.neuron.yale.edu/
* License : GPL
  Programming Lang: C, C++, Python
  Description : simulation environment for computational models of 
(networks of ) neurons

  NEURON is a simulation environment for modeling individual neurons and 
networks
  of neurons. It provides tools for conveniently building, managing, and using
  models in a way that is numerically sound and computationally efficient. It is
  particularly well-suited to problems that are closely linked to experimental
  data, especially those that involve cells with complex anatomical and
  biophysical properties.
  .
  NEURON offers
   * "natural syntax," which allows them to specify model properties in 
 familiar idioms
   * efficient and painless spatial and temporal discretization
   * several different, user-selectable numerical integration methods. 
   * convenient user interface (interpreters + GUI)
   * user-extendable library of biophysical mechanisms

This work will be carried out in collaboration with NEURON contributor,
Eilif Muller.  Very scarse initial packaging temporarily made available on
https://bitbucket.org/yarikoptic/nrn

Preliminary packages will be made available (whenever such) from
http://neuro.debian.net repository.



-- 
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/20100917135220.25661.59611.report...@novo.onerussian.com

Bug#597202: ITP: kstars-data-extra-tycho2 -- Contains the Tycho2 star catalog for centralized install, avoiding per-user install

[Noel David Torres Taño]

Package: wnpp
Severity: wishlist
Owner: "Noel David Torres Taño" 


Actually kstars offer each user to download some data, from the net, which 
causes bandwith and disk waste (See #596007). I will package one of those 
datafiles (one of the catalogs) to avoid that, and I want to package the 
remaining afterwards.

* Package name: kstars-data-extra-tycho2
  Version : 1.1r1
  Upstream Author : Akarsh Simha, Jason Harris 
* URL : 
http://edu.kde.org/kstars/downloads/tycho2_mag_12.5-1.1.tar.bz2
* License : GPL
  Programming Lang: N/A
  Description : Contains the Tycho2 star catalog for centralized install, 
avoiding per-user install

This package contains the data of the Tycho 2 star catalog that kstars would 
otherwise offer the user to download. Installing this package avoids the need 
for the users to each one download the catalog for itself. It is configurable 
if you want the users to be unable to do those downloads.



--
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/20100917144208.19140.79125.report...@tochox.rolamasao.org

Re: FTPMaster meeting, step1: New FTPMaster

[Barry deFreese]

Woohoo, congrats Torsten.

Again, I must apologize for my extended absence, work and personal life are 
just insane right now.
I hope it slows down in the winter and I will resume full duties. :(

Thanks,

Barry

On 9/17/2010 11:52 AM, Joerg Jaspert wrote:
> Heyho,
> 
> as you may have read in the past, there is a meeting of the FTPTeam this
> weekend.  And for fun and profit we decided to make Torsten Werner an
> FTPMaster (especially because he isn't here), so everybody please send your
> condolences (or congratulations, your call) to him now.
> 
> More to come later.
> 


-- 
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/4c9394a2.1060...@verizon.net

Re: RFC: Rules for distro-friendly packages

[Russ Allbery]

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 that our packaging tools can handle that case,
it's not clear to me why Debian should be telling upstreams they must not
do that.  (Although I'm increasingly getting the impression that your list
of guidelines is documentation of your personal coding style, not really
an effort to put together guidelines that Debian as a whole can agree to
advocate to upstreams.)

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

> Runtime test suites are different thing. I'm talking about the build
> process.

Oh, okay.  Maybe that should be somewhat clearer?

> What I want to prohibit is such cases where you start the build and it
> now starts some downloads or queries some servers, etc, all that risks
> making the build indeterministic and thus unreliable.

Yes, I agree with that.

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

> They should use --enable-*/--disable-* flags for switching features.

--enable/--disable is for internal features.  --with/--without is for
features that depend on external packages.  See the Autoconf
documentation.

> Switching dependencies which silently enables/disables features is a
> generally bad approach. Instead have feature switches and maybe tell
> what these features depend on.

Best practices for use of Autoconf is to force building the feature with
--with, force omitting the feature with --without, and to auto-detect
based on the presence of the external library if neither is given.  This
is what we should be recommending to upstream to use, IMO.

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

> Building static libraries (additional to shared/dynamic ones) usally
> is not a big task.

Except when it is, such as whenever you want to use some sort of dynamic
plugin architecture, which is increasingly common.  See also PAM modules,
NSS modules, etc.

> And still many people need them.

I'm dubious of this.

>> one can not yet commit to a stable ABI, and there are

> Why that exactly ?

Why do upstreams not commit to a stable ABI?  Usually because the software
is still under rapid development and they're not keeping track of which
changes change the public ABI.  It's not uncommon for libraries in their
very early stages of growth.

>> various situations (such as support for dynamic plugins) where
>> supporting them is a huge pain.

> In very most cases, that's bad design.

Um.  I'm not sure there's anything I can say to that other than "no, it's
not."

>> I strongly disagree with requiring pkg-config.  

> Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.

I doubt this a lot.  Details?

>> None of my libraries support this,

> Bad. You should fix this.

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 priority list.  I completely
disagree with any statement about upstream build practices that require
it.

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

> Because that doesn't always suffice.

Then use pkg-config or some other tool in the rare cases where it doesn't.

> It requires that the library is in the toolchain's standard search
> path.

That's what user-settable LDFLAGS in Autoconf is for, and that handles the
search paths for all libraries, whether they're using pkg-config or not.

> And what about cflags ?  What about dependencies ?

Most libraries do not need either of those things on any modern platform.
Are you really writing your guidelines to cater to HP-UX and IRIX?  I
agree that this sort of thing is useful there, but there are numerous
other portability issues to platforms that can't handle shared library
dependencies.  Most software is not going to build on those platforms
anyway, since doing so requires access to those platforms to do reasonable
testing and realize what changes have to be made.

Sure, if you're going to the work to port your software to ancient UNIX
platforms without shared li

Re: ITP: mbrola-{br1,de4,de5,es2,fr1,gr1,us3} -- Voices for Mbrola

[Georges Khaznadar]

Hello Samuel,

when I checked it one year ago, the license of mbrola's voices did not
allow redistribution.

Does this license allow to redistribute them now?

Best regards,   Georges.

Samuel Thibault a écrit :
> - Forwarded message from Samuel Thibault  -
> 
> From: Samuel Thibault 
> To: Debian Bug Tracking System 
> Subject: ITP: mbrola-br1 -- Brazilian Portuguese male voice for Mbrola
> Date: Tue, 14 Sep 2010 21:50:24 +0200
> User-Agent: Mutt/1.5.12-2006-07-14
> 
> Package: wnpp
> Version: N/A; reported 2010-09-14
> Severity: wishlist
> Owner: Samuel Thibault 
> 
> * Package name: mbrola-br1
>   Version : 2.021
>   Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
>  
> * URL : http://tcts.fpms.ac.be/synthesis
> * License : see the file readme.txt in the source zip: non-free as in
> without source code, and for non-commercial, non-military
> purposes, with and only with the mbrola package made
> available by the author.
>   Description : Brazilian Portuguese male voice for Mbrola
>  This package contains a Brazilian Portuguese diphone database provided in 
> the context
>  of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
>  .
>  It provides a Brazilian Portuguese male voice to be used with the MBROLA
>  program.
> 
> - End forwarded message -
> - Forwarded message from Samuel Thibault  -
> 
> From: Samuel Thibault 
> To: Debian Bug Tracking System 
> Subject: ITP: mbrola-de4 -- German male voice for Mbrola
> Date: Tue, 14 Sep 2010 21:50:40 +0200
> User-Agent: Mutt/1.5.12-2006-07-14
> 
> Package: wnpp
> Version: N/A; reported 2010-09-14
> Severity: wishlist
> Owner: Samuel Thibault 
> 
> * Package name: mbrola-de4
>   Version : 0.0.20020812
>   Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
>  
> * URL : http://tcts.fpms.ac.be/synthesis
> * License : see the file readme.txt in the source zip: non-free as in
> without source code, and for non-commercial, non-military
> purposes, with and only with the mbrola package made
> available by the author.
>   Description : German male voice for Mbrola
>  This package contains a German diphone database provided in the context
>  of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
>  .
>  It provides a German male voice to be used with the MBROLA
>  program.
> 
> - End forwarded message -
> - Forwarded message from Samuel Thibault  -
> 
> From: Samuel Thibault 
> To: Debian Bug Tracking System 
> Subject: ITP: mbrola-de5 -- German female voice for Mbrola
> Date: Tue, 14 Sep 2010 21:50:56 +0200
> User-Agent: Mutt/1.5.12-2006-07-14
> 
> Package: wnpp
> Version: N/A; reported 2010-09-14
> Severity: wishlist
> Owner: Samuel Thibault 
> 
> * Package name: mbrola-de5
>   Version : 1.0
>   Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
>  
> * URL : http://tcts.fpms.ac.be/synthesis
> * License : see the file readme.txt in the source zip: non-free as in
> without source code, and for non-commercial, non-military
> purposes, with and only with the mbrola package made
> available by the author.
>   Description : German female voice for Mbrola
>  This package contains a German diphone database provided in the context
>  of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
>  .
>  It provides a German female voice to be used with the MBROLA
>  program.
> 
> - End forwarded message -
> - Forwarded message from Samuel Thibault  -
> 
> From: Samuel Thibault 
> To: Debian Bug Tracking System 
> Subject: ITP: mbrola-es2 -- Spanish male voice for Mbrola
> Date: Tue, 14 Sep 2010 21:51:11 +0200
> User-Agent: Mutt/1.5.12-2006-07-14
> 
> Package: wnpp
> Version: N/A; reported 2010-09-14
> Severity: wishlist
> Owner: Samuel Thibault 
> 
> * Package name: mbrola-es2
>   Version : 2.069
>   Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
>  
> * URL : http://tcts.fpms.ac.be/synthesis
> * License : see the file readme.txt in the source zip: non-free as in
> without source code, and for non-commercial, non-military
> purposes, with and only with the mbrola package made
> available by the author.
>   Description : Spanish male voice for Mbrola
>  This package contains a Spanish diphone database provided in the context
>  of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
>  .
>  It provides a Spanish male voice to be used with the MBROLA
>  program.
> 
> - End forwarded message -
> - Forwarded message from Samuel Thibault  -
> 
> From: Samuel Thibault 
> To: Debian Bug Tracking System 
> Subject: ITP: mbrola-gr1 -- Gre

Re: ITP: mbrola-{br1,de4,de5,es2,fr1,gr1,us3} -- Voices for Mbrola

[Samuel Thibault]

Georges Khaznadar, le Fri 17 Sep 2010 19:34:51 +0200, a écrit :
> when I checked it one year ago, the license of mbrola's voices did not
> allow redistribution.
> Does this license allow to redistribute them now?

It does permit if you ask. I have asked, upstream agreed, so it's ok.
See the note in /usr/share/doc/mbrola/copyright.

Samuel


-- 
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/20100917174618.gz5...@const.bordeaux.inria.fr

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

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 world, I  have users that
>> are running  very old  distro and that  cannot upgrade it  nightly while
>> everything  works perfectly  ans just  need to  test the  software  on a
>> preprod system before trying to package it.

> I agree with your underlying point.  But there is absolutely no call
> for phrases like "keep living in your narrow-minded world".  I think
> you owe Enrico an apology.

> Please try to keep this list polite.  It is OK to disagree with
> people.  It is not OK to call them rude names.

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 rephrase with "Keep your
restricted view  on what  a user  is allowed to...".  I apology  for any
misunderstanding.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


pgpjDLaGtonex.pgp
Description: PGP signature

Bug#508644: Sorting out mail-transport-agent mess for squeeze

[Holger Levsen]

Hi,

 http://paste.debian.net/90185/ - thats on a squeeze system - any 
ideas?
 bitten by "my own" bug: #508644
 and ssmtp misses a provides: default-mta - is that serious, 
important, wishlist?

the log mentioned above is this: 

r...@sun:~# dpkg -l ssmtp
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
Description
+++-=-=-==
un  ssmtp (no 
description available)
r...@sun:~# apt-get install ssmtp
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  exim4-daemon-light
The following NEW packages will be installed:
  exim4-daemon-heavy
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 509kB of archives.
After this operation, 111kB of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://ftp.de.debian.org/debian/ squeeze/main exim4-daemon-heavy i386 
4.72-1 [509kB]
Fetched 509kB in 0s (5667kB/s)   
Preconfiguring packages ...
dpkg: exim4-daemon-light: dependency problems, but removing anyway as you 
requested:
 exim4 depends on exim4-daemon-light | exim4-daemon-heavy | 
exim4-daemon-custom; however:
  Package exim4-daemon-light is to be removed.
  Package exim4-daemon-heavy is not installed.
  Package exim4-daemon-custom is not installed.
 bsd-mailx depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package exim4-daemon-light which provides default-mta is to be removed.
  Package mail-transport-agent is not installed.
  Package exim4-daemon-heavy which provides mail-transport-agent is not 
installed.
  Package exim4-daemon-light which provides mail-transport-agent is to be 
removed.
 logcheck depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package exim4-daemon-light which provides default-mta is to be removed.
  Package mail-transport-agent is not installed.
  Package exim4-daemon-heavy which provides mail-transport-agent is not 
installed.
  Package exim4-daemon-light which provides mail-transport-agent is to be 
removed.
 bsd-mailx depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package exim4-daemon-light which provides default-mta is to be removed.
  Package mail-transport-agent is not installed.
  Package exim4-daemon-heavy which provides mail-transport-agent is not 
installed.
  Package exim4-daemon-light which provides mail-transport-agent is to be 
removed.
 logcheck depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package exim4-daemon-light which provides default-mta is to be removed.
  Package mail-transport-agent is not installed.
  Package exim4-daemon-heavy which provides mail-transport-agent is not 
installed.
  Package exim4-daemon-light which provides mail-transport-agent is to be 
removed.
(Reading database ... 51078 files and directories currently installed.)
Removing exim4-daemon-light ...
Stopping MTA: exim4_listener.
Processing triggers for man-db ...
Selecting previously deselected package exim4-daemon-heavy.
(Reading database ... 51050 files and directories currently installed.)
Unpacking exim4-daemon-heavy (from .../exim4-daemon-heavy_4.72-1_i386.deb) ...
Processing triggers for man-db ...
Setting up exim4-daemon-heavy (4.72-1) ...
Starting MTA: exim4.
[ Rootkit Hunter version 1.3.6 ]
File updated: searched for 162 files, found 129
r...@sun:~# apt-get install ssmtp
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  exim4-daemon-heavy
The following NEW packages will be installed:
  exim4-daemon-light
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 460kB of archives.
After this operation, 111kB disk space will be freed.
Do you want to continue [Y/n]? n
Abort.
r...@sun:~# 

I'm filing an important bug on ssmtp now.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: RFC: Rules for distro-friendly packages

[Yavor Doganov]

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, although they're often
misused and/or confused by upstream authors.  See (autoconf)External
Software' and the subsequent node, `(autoconf)Package Options'.

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

> > 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 
> 
> Building static libraries (additional to shared/dynamic ones) usally
> is not a big task.

I guess what Russ is trying to say is that they are completely useless
if just one library package in the dependency chain doesn't provide a
static lib.

> And still many people need them.

I seriously doubt that.  Many Debian library packages have been
gradually dropping static libraries in the past few years, and I don't
recall complaints.  I think the statement "many people need them" is
an exaggeration.

If someone really needs a static library, she is probably in a perfect
position and has the necessary knowledge/skills to build one herself.
As you say, that's easy :-).

> > I strongly disagree with requiring pkg-config.  
> 
> Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.

But pkg-config is notoriously bad when cross-compiling...  With pure
Autoconf macros (used properly, and providing an extra argument for
AC_RUN_IFELSE and friends), cross-compilation works out of the box.
If PKG_CHECK_MODULES is used, the installer has to go through extra
hoops.

> > None of my libraries support this,
> 
> Bad. You should fix this.

I don't think so.  It's entirely his prerogative whether to support it
or not, and it's perfectly fine not to use it.

> > 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.  
> 
> Because that doesn't always suffice. It requires that the library
> is in the toolchain's standard search path.

That's the case with pkg-config too.  If you install a library in
/opt/foo, pkg-config will not find it if you don't instruct it to look
there.

> And what about cflags ?  What about dependencies ?

What's wrong with checking for the libraries/headers in the right
dependency order?

Honestly, I've always wondered what's so attractive in pkg-config that
people use it so much.  All it does is parsing a .pc file, which fails
short in so many situations...  The version check pkg-config does is
simply a comparison with the version embodied in the .pc file, which
does not match the reality in some cases, and more importantly, is the
wrong approach -- the version check may succeed, but the library may
not provide the feature needed by the package (improper installation,
distro patch, sysadmin patch, forked software, anything else the
package developer *has not* anticipated).  And vice versa, which is
equally annoying -- the library provides the symbol (or the new
feature) the package needs, but the .pc file still contains the old
version, because usually it's bumped at release time.  Ugh.

You are basically right that using pkg-config is easier for many
upstreams, but "easy" != "correct".  Correctness is far more
important.  I also fail to see what has pkg-config to do with
distro-friendliness.  A distro maintainer by definition should be
familiar with the code, follow upstream development, examine diffs
between upstream releases (in the ideal case), and add the appropriate
build-dependencies when the new upstream version of the package needs
them (or could benefit from them).  pkg-config is not in the picture
at all.

> > It's a nice-to-have if upstream wants to bother, but is absolutely
> > not required.
> 
> For my setups, it *is* required.

Then you probably can't build lots of packages.  Many widely used
libraries with a truckload of reverse dependencies do not support
pkg-config, and there's nothing wrong in that.

> > 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.
> 
> Then you'll have to live with the fact, that other people won't
> like your libraries very much, for that reason.

That is an utterly wrong assumption, and I even find it slightly
insulting because it presumes that the quality of Russ' software is
somewhat lower than expected.

> > 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),

Very true.

> 

Bug#508644: Sorting out mail-transport-agent mess for squeeze

[Holger Levsen]

On Freitag, 17. September 2010, Holger Levsen wrote:
>  and ssmtp misses a provides: default-mta - is that serious,
> important, wishlist?
> I'm filing an important bug on ssmtp now.

aehm, no. 


signature.asc
Description: This is a digitally signed message part.

Bug#597228: ITP: minidlna -- server for DLNA/UPnP-AV clients

[Eric Cooper]

Package: wnpp
Severity: wishlist
Owner: Eric Cooper 

* Package name: minidlna
  Version : 1.0.18-1
  Upstream Author : Justin Maggard
* URL : http://sourceforge.net/projects/minidlna
* License : GPL and BSD
  Programming Lang: C
  Description : server for DLNA/UPnP-AV clients

MiniDLNA (aka ReadyDLNA) is server software with the aim of being
fully compliant with DLNA/UPnP-AV clients.

The minidlna daemon serves media files (music, pictures, and video)
to clients on your network.  Example clients include applications
such as totem and xbmc, and devices such as portable media players,
smartphones, televisions, and Blu-Ray players.

MiniDLNA is a simple, lightweight alternative to mediatomb, but has
fewer features. It does not have a web interface for administration
and must be configured by editing a text file.



-- 
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/20100917200824.5363.69144.report...@stratocaster.home

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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 telling upstreams they must not
> do that. 

That's probably fine for Debian, but my rules are meant to be generic,
not distro specific. And many other packaging systems do not support it.
Note that such cases add a lot of complexity to the whole QM and packaging
workflow, which should be avoided (that's one of the major goals of this
document: make the workflow as simple and defined as possible).

> >> 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.
> 
> > They should use --enable-*/--disable-* flags for switching features.
> 
> --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 features start to introduce dependencies.

And it's also the wrong methodology - it turns things upside down: from
a QM perspective you're interested in the function requirements or
features, and dependencies might be triggered by that (or might not to).

For example, an "--with-zlib" doesn't tell anything about what is really
done with zlib, what features are provided by that. It just tells that
zlib is *somehow* used. The right way would be some "--enable-compression"
which tells that our package can handle compression - the dependency to
zlib now is just an implication on that. (depencencies are implications,
not bijective relations).

> > Switching dependencies which silently enables/disables features is a
> > generally bad approach. Instead have feature switches and maybe tell
> > what these features depend on.
> 
> Best practices for use of Autoconf is to force building the feature with
> --with, force omitting the feature with --without, and to auto-detect
> based on the presence of the external library if neither is given.  This
> is what we should be recommending to upstream to use, IMO.

Yes, but this approach is dangerous. It relies on assumptions about the
target system, taken from the running/building system. I already had
cases where that caused a hell of trouble.

The purpose of my rules is to get rid of unexpected behaviour as much
as possible - this is one of the key points.

> > Building static libraries (additional to shared/dynamic ones) usally
> > is not a big task.
> 
> Except when it is, such as whenever you want to use some sort of dynamic
> plugin architecture, which is increasingly common.  See also PAM modules,
> NSS modules, etc.

PAM and NSS are inherently instable by design, just by the fact that code
it loaded at runtime which is not known at compile time (the toolchain can
serve no proper checks here, since the necessary information is simply not
available at this time) - very bad from a QM perspective.

And of course, that all cannot be used on systems where dynamic library
loading is not available at all.

> > And still many people need them.
> 
> I'm dubious of this.

It's required by much of my daily work.

> >> one can not yet commit to a stable ABI, and there are
> 
> > Why that exactly ?
> 
> Why do upstreams not commit to a stable ABI?  Usually because the software
> is still under rapid development and they're not keeping track of which
> changes change the public ABI.  It's not uncommon for libraries in their
> very early stages of growth.

Okay, in that case they simply have to do proper library versioning
(and if API also changes incompatibly, version the includes).
If upstream can't or doesn't want to do that, a separate layer in
the middle (eg. OSS-QM) has to step in, essentially forming an kind
of overlay or filter.

> >> various situations (such as support for dynamic plugins) where
> >> supporting them is a huge pain.
> 
> > In very most cases, that's bad design.
> 
> Um.  I'm not sure there's anything I can say to that other than "no, it's
> not."

We could play a little game: you tell me some cases where you think
that dynamic library loading is necessary, and I'll give you better
solutions ;-p

> >> I strongly disagree with requiring pkg-config.  
> 
> > Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.
> 
> I doubt this a lot.  Details?

Well, the major problem is that in many cases - especially when
crosscompiling - you cannot assume all libraries in standard
locations (those the upstream expects), and you also need to know
the library's own dependencies (not all targets/binfmt's have proper
dependency information, especially not on static libraries).

So you'll need some lookup mechanism (unless you want t

Bug#597245: ITP: gluon -- An open framework developing,playing and distributing games

[Andreas Marschke]

Package: wnpp
Severity: wishlist
Owner: Andreas Marschke 


* Package name: gluon
  Version : 0.70.0
  Upstream Author : Arjen Hiemstra  and others
* URL : http://gluon.gamingfreedom.org
* License : LGPL
  Programming Lang: C++
  Description : An open framework developing,playing and distributing games
   Gluon is a Free and Open Source framework for creating 
   and distributing games - supporting the flow of the 
   idea all the way from the author to the player of the 
   finished game, and back. 



-- 
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/20100918011741.29105.41446.report...@andreas.andreas

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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 maintainer or developer role, and
> >>>then you should *know* what you're doing (or at least learn it).
> >>[...]
> >>
> >>Hello, /usr/local...
> >
> >Should never be used.
> 
> no?

At least be _very_ careful, since it also can have very nasty
side effects, nobody wants on production systems.

> >I never said this. I dont want to forbid them anything. But as soon
> >as you're beginning to compile and install packages on yourself,
> >you're leaving the user role, and you should know what you're doing.
> >(or do it on some safe playgound).
> 
> I think you are confusing the word "users". For a distribution in
> "users" we include normal users (of a multiuser system), sysadmin,
> super users, programmers, and any person that install they own machine.

You should clearly differenciate between these roles, since they're
very different (even if the same person might be in several rules
at the same time).

> Many of such roles requires to compile and install customs programs.
> Linux always supported such behaviour.

Yes. But all these rules require certain skills for doing it right,
w/o shooting yourself. And GNU/Linux never was designed to protect
people for shooting themselves (certain distros are designed so,
but that's an different layer).


And again: I don't say that upstreams should not ship tarballs
including those autogenerated files. But they should ship some
canonical tree without them (modern VCS with proper tagging 
is fine, too).


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

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


-- 
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/20100918013805.gb18...@nibiru.local

Re: RFC: Rules for distro-friendly packages

[Russ Allbery]

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 features start to introduce dependencies.

[...]

I think I'm going to bow out.  Our concept of how to design good upstream
software and what best practices are for standard tools are sufficiently
different that I don't think further line-by-line discussion is really a
productive use of either of our time.

I've had on my long-term to-do list for some time writing up what I
consider to be best practices and good coding style for putting together
software distributions.  Hopefully I'll be able to find some time to do
that.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87k4mj960m@windlord.stanford.edu

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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 machines is put into that need because out of 
> his reach constrains? 

The sysadmins should run the build through a dedicated build system
which generates packages for their target(s). I'm currently working
on providing a generic platform for that, based on Briegel [1], but
that's another story.

BTW: if you want to build new software directly on old systems, you'll
sooner or later run into many other kinds of problems. For example 
think of bugs in older libc's or compilers which then would have to 
worked around in newer packages. That's nasty, nobody really likes that.
The answer is clear: use a dedidacted build system (eg. via sysroot'ed
crosscompiler), which produces the right code/packages for that old
systems. This way, eg. you don't have to care about broken or missing
libc functions on the target - an properly adapted toolchain takes
care of this.

> > On the other hand, there are often cases where you *NEED* to rebuild
> > the whole configure stuff.
> 
> Truly.  As there are cases when I have to go through the Makefile or
> even the source code to patch them so they run in my systems. But,
> please, do not make those cases more usual that *strictly* needed.

In last decade I've encountered so many of such cases, that I decided
to always regenerate these file and catch up problems at the earliest
point, at the source. So, eg., if regeneration fails, I first fix that.
Yes, this might take a bit more time to get some particular package
building and running, but in the longer run, it always had paid out.

> Because as much as any other software, autotools tend not to be forwards 
> compatible: as long as you use a feature from x+7.y.z it will probably fail 
> when runing older x.y.z.

Gentoo has an interesting handling for that: they support packages
requesting specific autoconf versions. I'm normally fixing it at
the source, but fixing packages to work w/ recent autoconf.

> You seem to forget that in the context of this discussion "arbitrary users" 
> are sysadmins on their duty.  They are perfectly expected to be recompiling 
> software on stable/production systems.  Heck, it's even there, on the FHS:

In this case, the admins are also put into the role of package
maintainer (of their own, 1-system distro) and QM engineer.
They should have the neccessary skills to do that, or leave it.

> > 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 least learn it).
> 
> Ah... those youngsters... package maintainers are a very convenient and most 
> praised *proxies* for the work of the sysadmin.

They're much more than this, they're also QM engineers that make sure,
individual packages play well in the ecosystem of their distro.
(at least they should do so).

> Of course "proper packages" are "better" but in many situations a make
> install onto /usr/local is good enough and "better" may change its meaning
> when dealing with half a dozen different unix-like systems.

It might be dangerous: adding some libraries to standard search pathes
can change behaviour of installed packages massively.

> > That's one of the fundamental conceptional flaws.
> 
> It might be the case, but then it's a "fundamental conceptional flaw" 
> from the very developers of the tool. 

Indeed, it is. This comes from autoconf's long history of hacked-up
macros, which has grown over years and years. Essentially it's an
large collection of hacks.

A really clean concept would be very different, it would use declarative
approaches, which allow central target-specific configuration, would
be written in easily understandable code, etc, etc.
If you'd like to work on such an system, be my guest, lets talk about that.

> > Users should use the finished packages provided by their distro.
> 
> As long as possible.

Always. If some package is missing, add it to the distro (maybe in a
local repo), using it's packaging toolchain. So, eg. for Debian, it
means, create Debian packages, do the proper QM works, and then install
the .dpkg.

> > > As upstream, I  care about Debian and cross-compiling  but I also should
> > > care about  people wanting to  compile my software  on old RHEL 2  or on
> > > Debian Etch (an  old enough platform to require some  runtime test in my
> > > case). None of those platforms have a recent enough autotools to rebuild
> > > configure, BTW.
> >
> > Then they should be updated.
> 
> Yeah, well... that's not so constructive. 

No, it is very constructive, since it's a clean way. Just package recent
autotools to RHEL 2. Shouldn't be that hard and solves the problem earlier
in the chain (and more generically, for more than ju

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* 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 appropriate for the social context.  It reads
> very much like a series of demands and instructions.

That might come from the backgroud that it's actually meant to
form a set of QM requirements. I'm going to implement an checklist
system for the OSS-QM project [1] where all the releases are
undergoing an approval process.

> 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 cannot / doesnt
want to follow the rules, OSS-QM can step in as man-in-the-middle ;-p


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

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


-- 
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/20100918065413.gd18...@nibiru.local