standard dependancy system

[Nicolas Mailhot]

Le dimanche 25 novembre 2007 à 16:35 +0100, Kai-Uwe Behrmann a écrit :
> Am 25.11.07, 13:42 +0100 schrieb Nicolas Mailhot:
> > Le dimanche 25 novembre 2007 à 12:44 +0100, Kai-Uwe Behrmann a écrit :
>  
> > Also don't forget that many distribution build for multiple arches, and
> > upstream authors have frequently been knwon to ignore their own warnings
> > in the first place.
> 
> Can you elaborate?

Meaning you have one build log per architecture, multiplied by
distribution releases, which is an awful lot of build logs to check.

And when you do check them and see funnies you often find that's a
problem the upstream authors know of but didn't bother to fix. They had
the same warning and ignored it when building their own binaries.

So checking build logs, while nice, is almost always a massive waste of
time. Except for projects that do fix every warning and where you know
any remaining message is a problem.

> > > Is a package featuring a plug-in system still the same when not delivered 
> > > with its plug-ins? Should at least the name say that it is not complete?
> > > Who decides about this? Should'nt the original maintainer have a last 
> > > say?
> > 
> > The maintainer has a say. If he makes the effort to document properly
> > his system people will take his wishes into account. If knowing his
> > wishes requires web site or mailing list archeology, he gets what he
> > sown.
> 
> What would be a good common place for this? A file called PACKAGING next 
> to README?

In Changelog and new release announces. Plus a README if you want.

> > > Distributors should be forceable to meet quite other standards.
> > 
> > Please add this at the start of your web sites so I know never to touch
> > anything you produced. Either you make it easy to do the "right
> 
> Please eighter quote me with appropriate context or let it be. You changed
> the content inacceptable. With the term forceable, I mean a software 
> mechanism, which enforces a upstream maintainer policy for 
> downstream distribution. This is quite obvious from te omited context.

That's what I understood. And I can tell you most every packager will
avoid like the plague an author who thinks he needs to force his policy
instead of fixing the bugs his software hits in the wild.

You only "need" to "force" a policy when your code doesn't work as-is,
and you refuse to assume this but want to force others to change their
environments so they don't hit your problems and you don't have to fix
them.

Having packaged software produced by entities with this kind of
attitude, I wan tell you bwawawa packagers will force your puny locks if
they have to, but that's more unpleasant work for them so they'd rather
ignore you completely and let you wonder why no distribution ships your
software.

Get out of your head people do not follow upstream policies because they
like making upstreams miserable. They do not follow upstream policies
because at some time upstreams made following their policies unappealing
(too hard, contrary to distro choices, not documented, take your pick).
If packagers did embark on a mission to make you miserable they'd flame
you publicly which is a lot less work and more ego satisfying anyway.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.freedesktop.org/archives/xdg/attachments/20071125/8a2e0ab2/attachment.pgp