mass bug gnustep programs: policy violation
Dan Weber
upon gnustep-base1 and themselves. They break Section 9.1.1 of the
Debian Policy.
Using /usr/lib/GNUstep for non-lib and executable binaries for direct
invocation is not permitted.
With Given Permission, I have quoted some logs from IRC to be included.
<trave11er> dan2: what's the violation?
<dan2> trave11er: breaks FHS compliance (9.1.1)
<trave11er> in what way?
<dan2> trave11er: installing binaries, documentation, etc in to
/usr/lib/GNUstep
<dan2> even /usr/lib/GNUstep is a violation even if it was only libs
<trave11er> binaries in /usr/lib/package are ok, as far as they are not
supposed to be run by end users
<dan2> this for instace -->
/usr/lib/GNUstep/System/Applications/Gorm.app/Gorm
<dan2> trave11er: but they are to be run by the user
<trave11er> dan2: directly?
<dan2> yes
<trave11er> it is not a symbolic link?
<dan2> no
<dan2> let me debrief you rather quickly on using gnustep applications
<dan2> to use a GNUstep application you first have to do this
<dan2> source /usr/lib/GNUstep/System/Library/Makefiles/GNUstep.sh
<dan2> then you use a program called openapp which is located in
/usr/lib/GNUstep/System/Tools/openapp
<trave11er> i used windowmaker in the past, i do not recall that i had
to do anything like that
<dan2> openapp will then load the program from /usr/lib/GNUstep/Applications
<dan2> trave11er: windowmaker does not, only gnustep applications
<dan2> windowmaker is not a gnustep application
Jérôme Warnier
> There is a serious policy violation regarding all programs dependant
> upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> Debian Policy.
>
> Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> invocation is not permitted.
packagers say that for such huge applications, having files all around
the system is more a problem than violating FHS.
[..]
--
Jérôme Warnier
Consultant
BeezNest
http://beeznest.net
Dan Weber
> Le mar 22/06/2004 à 05:35, Dan Weber a écrit :
>
>>There is a serious policy violation regarding all programs dependant
>>upon gnustep-base1 and themselves. They break Section 9.1.1 of the
>>Debian Policy.
>>
>>Using /usr/lib/GNUstep for non-lib and executable binaries for direct
>>invocation is not permitted.
>
> Mozilla and OpenOffice.org also violate the FHS in a similar way. The
> packagers say that for such huge applications, having files all around
> the system is more a problem than violating FHS.
>
> [..]
>
Why should we let this go by? The Debian Policy sets rules for all
packages not just some, thus similar bugs should be filed against
mozilla and openoffice.org.
Dan Weber
Francesco P. Lovergine
> Jérôme Warnier wrote:
For instance because many huge programs are built by defining an
APPLICATION_DIR and creating a complicated tree of other dirs there,
with a large mess of libs, bins and data all mixed together.
This is a very traditional approach in the *nix world. Moving from
that approach could require heavy patching. You know, not all
programs are written with the needed flexibility and some
of them are multi-platform (e.g.mozilla, ooffice) and
need to find bad arch compromises for non-nix worlds. That's for
general theory...
In the specific case you point, files could be probably moved in
the right places and a sym link could be created in /usr/lib/<app>
to avoid breaking the application. That will be used 'internally'
and so will be ok by the FHS pov.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Florian Weimer
>> Mozilla and OpenOffice.org also violate the FHS in a similar way. The
>> packagers say that for such huge applications, having files all around
>> the system is more a problem than violating FHS.
>> [..]
> Why should we let this go by? The Debian Policy sets rules for all
> packages not just some, thus similar bugs should be filed against
> mozilla and openoffice.org.
It's an issue that has to be addressed in Policy or in the FHS. It's
not really a defect in thos packages (IMHO).
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
Sebastian Ley
> There is a serious policy violation regarding all programs dependant
> upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> Debian Policy.
>
> Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> invocation is not permitted.
Yeah, the OpenStep directory layout is not compliant with the FHS layout,
although they share similar design principles. For those who are not familiar
with it:
OpenStep defines four domains: System, Network, Local and User. These domains
have the same layout and are rooted into different directories in the
directory tree.
System domain is reserved for all stuff related installed by the system,
pretty much maps to the understanding of the /usr tree in FHS. GNUstep roots
it to /usr/lib/GNUstep/System
Network domain is meant to be mounted remotely and denotes part of the
installation common among machines in a network. GNUstep roots it
to /usr/local/lib/GNUstep/Network
Local domain contains stuff which is local to the machine, i.e. maps to the
concept of /usr/local of FHS. GNUstep roots it
to /usr/local/lib/GNUstep/Local
User domain is reserved for stuff installed by individual users. Maps to FHS
home directories, but is more flexible: a user should bbe able to install
anything up to whole programs to his USER_ROOT and could use them as if they
were installed by the asministrator. GNUstep roots it to ~/GNUstep.
As mentioned before these domains share the same layout, i.e. they all have
subdiretories /Applications, /Library, /Tools with /Library containing all
kind of different sutuff which would belong into /include, /share, /lib
directories according to FHS.
Starting to mass-file bugs against all GNUstep programs would do no good in my
opinion. We need to find a solution on how to integrate these apps into the
FHS.
One possibility could be to adjust gnustep-make to install to FHS compliant
paths. gnustep-make is a collection of makefiles which are used to compile
and install all GNUstep programs. If it was possible to alter the
installation paths and at the same time ensure that applications still find
their resources, this would be the most clean solution. I don't know what the
GNUstep folks think about this, we should engage in conversation.
Regards,
Sebastian
--
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Christoph Hellwig
> In the specific case you point, files could be probably moved in
> the right places and a sym link could be created in /usr/lib/<app>
> to avoid breaking the application. That will be used 'internally'
> and so will be ok by the FHS pov.
For those large and crappy application suites the FHS has
/opt/<package>/
Francesco P. Lovergine
> On Tue, Jun 22, 2004 at 11:56:00AM +0200, Francesco P. Lovergine wrote:
> > In the specific case you point, files could be probably moved in
> > the right places and a sym link could be created in /usr/lib/<app>
> > to avoid breaking the application. That will be used 'internally'
> > and so will be ok by the FHS pov.
>
> For those large and crappy application suites the FHS has
> /opt/<package>/
>
AFAIK the use of /opt, /etc/opt and /var/opt is reserved to
application software packages.
That was typically (but not exclusively), commercial or
proprietary one in the old good (?) days, installed by the
administrator and produced by third parties (i.e. not
the OS vendor).
Unfortunately today we cannot define easily
the difference among an application software and all the
rest. My own interpretation is that all (and only) software
packaged out of the distribution is ideed application software.
So, no parts of Debian should stay there.
--
Francesco P. Lovergine
Christoph Hellwig
> AFAIK the use of /opt, /etc/opt and /var/opt is reserved to
> application software packages.
Which is exactly what openoffice and mozilla are.
Philip Miller
> Le mar 22/06/2004 ŕ 05:35, Dan Weber a écrit :
>
>>There is a serious policy violation regarding all programs dependant
>>upon gnustep-base1 and themselves. They break Section 9.1.1 of the
>>Debian Policy.
>>
>>Using /usr/lib/GNUstep for non-lib and executable binaries for direct
>>invocation is not permitted.
>
> Mozilla and OpenOffice.org also violate the FHS in a similar way. The
> packagers say that for such huge applications, having files all around
> the system is more a problem than violating FHS.
I just looked at the output of dpkg -L mozilla-browser, and I don't see
anything that violates the FHS in the way described.
/usr/mozilla/mozilla-bin is not meant for direct invocation by the user,
because there is a shell script shipped as /usr/bin/mozilla-1.6 that sets up
the environment for it before it runs.
Everything else seems to fit in to /usr/lib just fine.
Philip Miller
Jaldhar H. Vyas
> AFAIK the use of /opt, /etc/opt and /var/opt is reserved to
> application software packages.
> That was typically (but not exclusively), commercial or
> proprietary one in the old good (?) days, installed by the
> administrator and produced by third parties (i.e. not
> the OS vendor).
> Unfortunately today we cannot define easily
> the difference among an application software and all the
> rest. My own interpretation is that all (and only) software
> packaged out of the distribution is ideed application software.
> So, no parts of Debian should stay there.
>
FWIW, this is my policy:
1. Anything packaged in .deb format -> standard FHS directories
2. Anything packaged in any other format (i.e. vmware which has its own
installer and upgrade method -> /opt
3. Everything else -> /usr/local
Thus I for one would prefer not to have some Debian package mess with /opt.
--
Jaldhar H. Vyas <jal...@debian.org>
La Salle Debain - http://www.braincells.com/debian/
Andreas Barth
> There is a serious policy violation regarding all programs dependant
> upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> Debian Policy.
>
> Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> invocation is not permitted.
Well, though I agree that this is a serious bug, I consider it
inappropriate to try to deal with this pre-sarge. If we want to get
sarge out, we can't always insists on doing major changes to complex
packages _now_.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Francesco Paolo Lovergine
> On Tue, 22 Jun 2004, Francesco P. Lovergine wrote:
>
> > AFAIK the use of /opt, /etc/opt and /var/opt is reserved to
> > application software packages.
> > That was typically (but not exclusively), commercial or
> > proprietary one in the old good (?) days, installed by the
> > administrator and produced by third parties (i.e. not
> > the OS vendor).
> > Unfortunately today we cannot define easily
> > the difference among an application software and all the
> > rest. My own interpretation is that all (and only) software
> > packaged out of the distribution is ideed application software.
> > So, no parts of Debian should stay there.
> >
>
> FWIW, this is my policy:
>
> 1. Anything packaged in .deb format -> standard FHS directories
>
It's a very dangerous policy. Files under system tree out of
/opt and /usr/local could potentially compromise system integrity.
And none can ensure that future debian packages won't overwrite your
local stuff. IMHO also packaging backports out of /opt is a very
bad practice and could create problems in dist-upgrades.
> 2. Anything packaged in any other format (i.e. vmware which has its own
> installer and upgrade method -> /opt
>
> 3. Everything else -> /usr/local
>
That's right.
--
Francesco P. Lovergine
Jaldhar H. Vyas
> It's a very dangerous policy. Files under system tree out of
> /opt and /usr/local could potentially compromise system integrity.
> And none can ensure that future debian packages won't overwrite your
> local stuff. IMHO also packaging backports out of /opt is a very
> bad practice and could create problems in dist-upgrades.
Oh well I should have added that I'm assuming anyone clueful enough to
provide a .deb at all is also clueful enough to be following the Debian
policy manual. But actually so far I haven't actually run into many
third-party .debs so that part of my policy is mostly just theory.
--
Jaldhar H. Vyas <jal...@debian.org>
La Salle Debain - http://www.braincells.com/debian/
Chris Cheney
> * Dan Weber (d...@mirrorlynx.com) [040622 05:40]:
> > There is a serious policy violation regarding all programs dependant
> > upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> > Debian Policy.
> >
> > Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> > invocation is not permitted.
>
> Well, though I agree that this is a serious bug, I consider it
> inappropriate to try to deal with this pre-sarge. If we want to get
> sarge out, we can't always insists on doing major changes to complex
> packages _now_.
They could just be removed from sarge and be released again with
sarge+1... Not every package with a RC bug has to be fixed and released
with sarge, it is common practice to pull them if they don't get fixed
in time.
Chris
Andreas Barth
You're not really suggesting to not release gnustep in sarge?
Dan Weber
>[snip] Not every package with a RC bug has to be fixed and released
> with sarge, it is common practice to pull them if they don't get fixed
> in time.
>
> Chris
The time till Sarge's release could be months, I am sure there is time
to fix it. Hey gnome2.6 made it in :)
Dan Weber
Matthew Palmer
> * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
> > sarge+1... Not every package with a RC bug has to be fixed and released
> > with sarge, it is common practice to pull them if they don't get fixed
> > in time.
>
> You're not really suggesting to not release gnustep in sarge?
That's what we do with packages that aren't of release quality.
- Matt
Colin Watson
> Chris Cheney wrote:
> >[snip] Not every package with a RC bug has to be fixed and released
> >with sarge, it is common practice to pull them if they don't get fixed
> >in time.
>
> to fix it. Hey gnome2.6 made it in :)
... over initial objections, with considerable back-and-forth with the
release team, and it's broken testing in a way we still haven't quite
managed to fix. Please don't take it as a precedent.
Cheers,
--
Colin Watson [cjwa...@flatline.org.uk]
Dan Weber
> On Wed, Jun 23, 2004 at 11:30:58PM -0400, Dan Weber wrote:
>
>>Chris Cheney wrote:
>>
>>>[snip] Not every package with a RC bug has to be fixed and released
>>>with sarge, it is common practice to pull them if they don't get fixed
>>>in time.
>>
>>The time till Sarge's release could be months, I am sure there is time
>>to fix it. Hey gnome2.6 made it in :)
>
>
> ... over initial objections, with considerable back-and-forth with the
> release team, and it's broken testing in a way we still haven't quite
> managed to fix. Please don't take it as a precedent.
>
> Cheers,
>
Anyhow, how does someone file a bug against all these packages at once.
All packages with this problem build-dep on gnustep-make.
Dan Weber
Andreas Barth
> On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote:
> > * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
> > > They could just be removed from sarge and be released again with
> > > sarge+1... Not every package with a RC bug has to be fixed and released
> > > with sarge, it is common practice to pull them if they don't get fixed
> > > in time.
> > You're not really suggesting to not release gnustep in sarge?
> That's what we do with packages that aren't of release quality.
Do you really and honestly believe that this bug means that gnustep is
not of release quality. In my opinion, these bugs are non-blockers for
sarge, and one of the issues that should be fixed for sarge+1.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Andreas Barth
> Chris Cheney wrote:
> >[snip] Not every package with a RC bug has to be fixed and released
> >with sarge, it is common practice to pull them if they don't get fixed
> >in time.
> The time till Sarge's release could be months, I am sure there is time
> to fix it. Hey gnome2.6 made it in :)
This is exactly what's keeping sarge non-releasable: We change core
functionality far too often. _Please_ don't do it. Please just accept
that we are near a release, and that we don't want to change basic
functionality now.
Dan Weber
> * Matthew Palmer (mpa...@debian.org) [040624 05:55]:
>
>>On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote:
>>
>>>* Chris Cheney (cch...@cheney.cx) [040623 20:55]:
>>>
>>>>They could just be removed from sarge and be released again with
>>>>sarge+1... Not every package with a RC bug has to be fixed and released
>>>>with sarge, it is common practice to pull them if they don't get fixed
>>>>in time.
>
>
>>>You're not really suggesting to not release gnustep in sarge?
>
>
>
>>That's what we do with packages that aren't of release quality.
>
>
> Do you really and honestly believe that this bug means that gnustep is
> not of release quality. In my opinion, these bugs are non-blockers for
> sarge, and one of the issues that should be fixed for sarge+1.
>
>
>
> Cheers,
> Andi
No package is an exception to debian policy except for maybe any of the
old GFDL crap in coreutils. If they[the maintainers] don't want to meet
debian standards these packages don't deserve to be in Debian.
Dan Weber
Matthew Palmer
> * Matthew Palmer (mpa...@debian.org) [040624 05:55]:
> > On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote:
> > > * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
> > > > They could just be removed from sarge and be released again with
> > > > sarge+1... Not every package with a RC bug has to be fixed and released
> > > > with sarge, it is common practice to pull them if they don't get fixed
> > > > in time.
>
> > > You're not really suggesting to not release gnustep in sarge?
>
> > That's what we do with packages that aren't of release quality.
>
> Do you really and honestly believe that this bug means that gnustep is
> not of release quality.
Yes.
It's not as though the requirement of FHS compliance is new or anything. If
the GNUstep maintainers can not or will not comply with the policy, either
(a) the policy needs to be reviewed as to whether it's impractical, or (b)
the non-compliant packages need to be removed.
So far, all I've seen is people saying that GNUstep doesn't need to follow
Policy, which I cannot agree with.
If a coherent argument can be made for why Policy should be changed to allow
GNUstep's current behaviour, it should be made. Policy isn't infallible,
and it might be that GNUstep benefits sufficiently from it's differing
structure that it should be allowed. However, the current structure works
well as far as I can see, and gratuitous differences should be avoided -- we
are trying to create consistency here, not cater for every project's
individual little foibles.
> In my opinion, these bugs are non-blockers for sarge, and one of the
> issues that should be fixed for sarge+1.
Ultimately, of course, the only opinion that matters for this is the RM and
his cohort of happy hackers. That's neither of us. You say it's non-RC RC,
I say it's RC RC. We'll probably have to agree to differ.
- Matt
"I don't agree to that"
Andreas Barth
replies as d-release is not a discussion list.]
* Matthew Palmer (mpa...@debian.org) [040624 09:55]:
> On Thu, Jun 24, 2004 at 09:01:43AM +0200, Andreas Barth wrote:
> > * Matthew Palmer (mpa...@debian.org) [040624 05:55]:
> > > On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote:
> > > > * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
> > > > > They could just be removed from sarge and be released again with
> > > > > sarge+1... Not every package with a RC bug has to be fixed and released
> > > > > with sarge, it is common practice to pull them if they don't get fixed
> > > > > in time.
> >
> > > > You're not really suggesting to not release gnustep in sarge?
> > > That's what we do with packages that aren't of release quality.
> > Do you really and honestly believe that this bug means that gnustep is
> > not of release quality.
> (a) the policy needs to be reviewed as to whether it's impractical, or (b)
> the non-compliant packages need to be removed.
>
> So far, all I've seen is people saying that GNUstep doesn't need to follow
> Policy, which I cannot agree with.
No, I didn't say that. I just said that this behaviour is
1. an important, but not serious bug
2. that changing this behaviour at the given moment of time would do
the package and the release a dis-favour, and the changing itself
would constitute a serious bug.
> > In my opinion, these bugs are non-blockers for sarge, and one of the
> > issues that should be fixed for sarge+1.
> Ultimately, of course, the only opinion that matters for this is the RM and
> his cohort of happy hackers. That's neither of us. You say it's non-RC RC,
> I say it's RC RC. We'll probably have to agree to differ.
Good. We seem to agree on that.
Please, can someone of the RMs say whether this bug should be solved
before or after release of sarge? (Or do you want to wait with a
statement on this until the GR is decided?)
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Manoj Srivastava
> * Matthew Palmer (mpa...@debian.org) [040624 05:55]:
>> On Wed, Jun 23, 2004 at 09:15:43PM +0200, Andreas Barth wrote:
>> > * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
>> > > They could just be removed from sarge and be released again
>> > > with sarge+1... Not every package with a RC bug has to be fixed
>> > > and released with sarge, it is common practice to pull them if
>> > > they don't get fixed in time.
>> > You're not really suggesting to not release gnustep in sarge?
>> That's what we do with packages that aren't of release quality.
> Do you really and honestly believe that this bug means that gnustep
> is not of release quality. In my opinion, these bugs are
> non-blockers for sarge, and one of the issues that should be fixed
> for sarge+1.
Not following the FHS does seem like a release issue to me --
though that decision rests with the RM team.
manoj
--
"He don't know me vewy well, DO he?" -- Bugs Bunny
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> * Chris Cheney (cch...@cheney.cx) [040623 20:55]:
>> On Tue, Jun 22, 2004 at 09:58:56PM +0200, Andreas Barth wrote:
>> > * Dan Weber (d...@mirrorlynx.com) [040622 05:40]:
>> > > There is a serious policy violation regarding all programs
>> > > dependant upon gnustep-base1 and themselves. They break
>> > > Section 9.1.1 of the Debian Policy.
>> > >
>> > > Using /usr/lib/GNUstep for non-lib and executable binaries for
>> > > direct invocation is not permitted.
>> > Well, though I agree that this is a serious bug, I consider it
>> > inappropriate to try to deal with this pre-sarge. If we want to
>> > get sarge out, we can't always insists on doing major changes to
>> > complex packages _now_.
>> They could just be removed from sarge and be released again with
>> sarge+1... Not every package with a RC bug has to be fixed and
>> released with sarge, it is common practice to pull them if they
>> don't get fixed in time.
> You're not really suggesting to not release gnustep in sarge?
Why not, if it violates something like the FHS, which isfar
from a new requirement for Debian packages? Are going to let
standards conformance and quality suffer in our headlong rush to
release something, anything, just release now rush?
manoj
--
Don't vote -- it only encourages them!
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> * Dan Weber (d...@mirrorlynx.com) [040624 05:40]:
>> Chris Cheney wrote:
>> >[snip] Not every package with a RC bug has to be fixed and
>> >released with sarge, it is common practice to pull them if they
>> >don't get fixed in time.
>> The time till Sarge's release could be months, I am sure there is
>> time to fix it. Hey gnome2.6 made it in :)
> This is exactly what's keeping sarge non-releasable: We change core
> functionality far too often. _Please_ don't do it. Please just
> accept that we are near a release, and that we don't want to change
> basic functionality now.
Hopefully the desire to release immediately has not thrown
every other consideration out of the window, like standards
conformance, quality, and policy compliance, and so on, that makes
Debian a desirable OS.
We used to not release until we were ready. And this
violation of the FHS seems like an indication that perhaps gnustep
packages are not yet ready -- do you have any arguments as to why we
must release these packages before they match our policies?
manoj
--
This dungeon is owned and operated by Frobozz Magic Co., Ltd.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> * Matthew Palmer (mpa...@debian.org) [040624 09:55]:
>> So far, all I've seen is people saying that GNUstep doesn't need to
>> follow Policy, which I cannot agree with.
> No, I didn't say that. I just said that this behaviour is
> 1. an important, but not serious bug
If it violates policy, it is a serious bug. Whether or not it
is RC depends on the RM.
manoj
--
One's own misdirected thought can do one more harm than an enemy or an
ill-wisher. 42
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Brian Nelson
> On Thu, 24 Jun 2004 09:15:20 +0200, Andreas Barth <a...@not.so.argh.org> said:
>
>> This is exactly what's keeping sarge non-releasable: We change core
>> functionality far too often. _Please_ don't do it. Please just
>> accept that we are near a release, and that we don't want to change
>> basic functionality now.
>
> Hopefully the desire to release immediately has not thrown
> every other consideration out of the window, like standards
> conformance, quality, and policy compliance, and so on, that makes
> Debian a desirable OS.
>
> We used to not release until we were ready. And this
> violation of the FHS seems like an indication that perhaps gnustep
> packages are not yet ready -- do you have any arguments as to why we
> must release these packages before they match our policies?
Because they've been packaged this way for a long time and work the way
they are now?
(I'm indifferent to the outcome of GNUStep in sarge--just pointing out
the other side of the argument.)
--
You win again, gravity!
Stephen Gran
> Anyhow, how does someone file a bug against all these packages at once.
> All packages with this problem build-dep on gnustep-make.
>
> Dan Weber
grep-dctrl -F Build-Depends gnustep-make -sPackage,Maintainer /var/lib/apt/lists/*
File bugs asking for rebuild after gnustep-make is fixed, I would guess.
I know neither Gnustep nor gnustep-make, so I offer this only as a
suggestion. I assume there are many more Gnustep packages that get
installed in a wrong location by default, that don't use gnustep-make.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Manoj Srivastava
> Manoj Srivastava <sriv...@debian.org> writes:
>> On Thu, 24 Jun 2004 09:15:20 +0200, Andreas Barth
>> <a...@not.so.argh.org> said:
>>
>>> This is exactly what's keeping sarge non-releasable: We change
>>> core functionality far too often. _Please_ don't do it. Please
>>> just accept that we are near a release, and that we don't want to
>>> change basic functionality now.
>>
>> Hopefully the desire to release immediately has not thrown every
>> other consideration out of the window, like standards conformance,
>> quality, and policy compliance, and so on, that makes Debian a
>> desirable OS.
>>
>> We used to not release until we were ready. And this violation of
>> the FHS seems like an indication that perhaps gnustep packages are
>> not yet ready -- do you have any arguments as to why we must
>> release these packages before they match our policies?
> Because they've been packaged this way for a long time and work the
> way they are now?
A long standing bug is nevertheless a bug.
manoj
--
In a medium in which a News Piece takes a minute and an "In-Depth"
Piece takes two minutes, the Simple will drive out the Complex. --
Frank Mankiewicz
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Matthias Klose
> Jérôme Warnier wrote:
> >
> >>There is a serious policy violation regarding all programs dependant
> >>upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> >>Debian Policy.
> >>
> >>Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> >>invocation is not permitted.
> >
> > Mozilla and OpenOffice.org also violate the FHS in a similar way. The
> > packagers say that for such huge applications, having files all around
> > the system is more a problem than violating FHS.
>
> I just looked at the output of dpkg -L mozilla-browser, and I don't see
> anything that violates the FHS in the way described.
> /usr/mozilla/mozilla-bin is not meant for direct invocation by the user,
> because there is a shell script shipped as /usr/bin/mozilla-1.6 that sets up
> the environment for it before it runs.
how does this differ from, i.e. the gnumail package providing the
wrapper as /usr/bin/gnumail?
Matthias Klose
programs dependant upon gnustep-base1". In the case of gorm this can
be fixed by providing a wrapper script in /usr/bin, as it's done for
not only a handful of packages.
Provided this fix satisfies you concerns, please file bug reports for
the appropriate packages. If you do have other concerns please state
how these should be addressed.
Your help as a GNUstep user and Debian developer would be appreciated.
Matthias
Dan Weber writes:
> There is a serious policy violation regarding all programs dependant
> upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> Debian Policy.
>
> Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> invocation is not permitted.
>
>
> With Given Permission, I have quoted some logs from IRC to be included.
>
> <trave11er> dan2: what's the violation?
> <dan2> trave11er: breaks FHS compliance (9.1.1)
> <trave11er> in what way?
> <dan2> trave11er: installing binaries, documentation, etc in to
> /usr/lib/GNUstep
> <dan2> even /usr/lib/GNUstep is a violation even if it was only libs
> <trave11er> binaries in /usr/lib/package are ok, as far as they are not
> supposed to be run by end users
> <dan2> this for instace -->
> /usr/lib/GNUstep/System/Applications/Gorm.app/Gorm
> <dan2> trave11er: but they are to be run by the user
> <trave11er> dan2: directly?
> <dan2> yes
> <trave11er> it is not a symbolic link?
> <dan2> no
> <dan2> let me debrief you rather quickly on using gnustep applications
> <dan2> to use a GNUstep application you first have to do this
> <dan2> source /usr/lib/GNUstep/System/Library/Makefiles/GNUstep.sh
> <dan2> then you use a program called openapp which is located in
> /usr/lib/GNUstep/System/Tools/openapp
> <trave11er> i used windowmaker in the past, i do not recall that i had
> to do anything like that
> <dan2> openapp will then load the program from /usr/lib/GNUstep/Applications
> <dan2> trave11er: windowmaker does not, only gnustep applications
> <dan2> windowmaker is not a gnustep application
Steve Langasek
> [Adding d-release because of the last question; please drop it on
> replies as d-release is not a discussion list.]
> > > Do you really and honestly believe that this bug means that gnustep is
> > > not of release quality.
> > (a) the policy needs to be reviewed as to whether it's impractical, or (b)
> > the non-compliant packages need to be removed.
> > So far, all I've seen is people saying that GNUstep doesn't need to follow
> > Policy, which I cannot agree with.
> No, I didn't say that. I just said that this behaviour is
> 1. an important, but not serious bug
> 2. that changing this behaviour at the given moment of time would do
> the package and the release a dis-favour, and the changing itself
> would constitute a serious bug.
Placing executables under /usr/lib/<package>/ is not a violation of the
FHS; it's often sufficient for the author to assert that the binaries
are not intended to be executed directly by the user for us to accept
that this is the case. The fact that there is an "openapp" helper
utility that's the recommended way to invoke these programs is further
evidence of this; this is quite different than if the recommended
invocation involved adding /usr/lib/GNUStep/<...>/<...>/ to your PATH or
calling the binary with an absolute path.
If you wish to argue that certain apps *should* be directly executable
by the user, you may, but this does not constitute a serious bug.
OTOH, expecting users to source a script to set up the GNUStep
environment before being able to invoke *any* of these apps is a policy
violation; as is placing arch-independent data under /usr/lib/GNUStep.
Per <http://people.debian.org/~ajt/sarge_rc_policy.txt>, these sorts of
bugs are considered RC for sarge. I would not say that an exemption for
these pre-existing bugs is impossible, but I also would not advise the
maintainers to expect such an exemption in the absence of evidence that
they have first put forth an effort to resolve this problem in the time
remaining before sarge's release.
--
Steve Langasek
postmodern programmer
Francesco P. Lovergine
> > There is a serious policy violation regarding all programs dependant
> > upon gnustep-base1 and themselves. They break Section 9.1.1 of the
> > Debian Policy.
> >
> > Using /usr/lib/GNUstep for non-lib and executable binaries for direct
> > invocation is not permitted.
>
> Well, though I agree that this is a serious bug, I consider it
> inappropriate to try to deal with this pre-sarge. If we want to get
> sarge out, we can't always insists on doing major changes to complex
> packages _now_.
>
>
Maybe I'm missing something, but
what's the problem in moving the violating file in the right directories
and leaving symlinks in /usr/lib/GNUstep?
This is a very easy workaround and removes the FHS problems.
--
Francesco P. Lovergine
Andreas Barth
> If it violates policy, it is a serious bug. Whether or not it
> is RC depends on the RM.
Hm, according to http://release.debian.org/sarge_rc_policy.txt:
| The purpose of this document is to be a correct, complete and canonical
| list of issues that merit a "serious" bug under the clause "a severe
| violation of Debian policy".
So, if this statement is true, than it's up to the release managers if
a policy violation is a serious or not.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Branden Robinson
> Hopefully the desire to release immediately has not thrown
> every other consideration out of the window,
As Ayn Rand would say:
Check your premises.
:-(
--
G. Branden Robinson | What influenced me to atheism was
Debian GNU/Linux | reading the Bible cover to cover.
bra...@debian.org | Twice.
http://people.debian.org/~branden/ | -- J. Michael Straczynski
Branden Robinson
> Maybe I'm missing something, but what's the problem in moving the
> violating file in the right directories and leaving symlinks in
> /usr/lib/GNUstep? This is a very easy workaround and removes the FHS
> problems.
Yes; I reckon that's what will happen with /usr/X11R6 one day.
/usr/X11R6 isn't RC (or a policy violation) because the FHS explicitly
grandfathers it. As far as I know, that's the *only* reason it isn't
RC, or a policy violation.
--
G. Branden Robinson | It's extremely difficult to govern
Debian GNU/Linux | when you control all three branches
bra...@debian.org | of government.
http://people.debian.org/~branden/ | -- John Feehery
Anibal Monsalve Salazar
>On Thu, 24 Jun 2004 10:35:34 +0200, Andreas Barth <a...@not.so.argh.org> said:
>
>>* Matthew Palmer (mpa...@debian.org) [040624 09:55]:
>>>So far, all I've seen is people saying that GNUstep doesn't need to
>>>follow Policy, which I cannot agree with.
>
>>No, I didn't say that. I just said that this behaviour is
>>1. an important, but not serious bug
>
> If it violates policy, it is a serious bug.
I agree.
> Whether or not it is RC depends on the RM.
I don't agree. It doesn't depend on the RM. The RM doesn't decide about
policy compliance.
> manoj
>--
>One's own misdirected thought can do one more harm than an enemy or an
>ill-wisher. 42
>Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
>1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
>1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Regards,
Anibal Monsalve Salazar
--
.''`. Debian GNU/Linux | Building 28C
: :' : Free Operating System | Monash University VIC 3800, Australia
`. `' http://debian.org/ | http://www-personal.monash.edu/~anibal/
`- |
Matthew Palmer
> On Thu, Jun 24, 2004 at 02:32:31PM -0500, Manoj Srivastava wrote:
> > Whether or not it is RC depends on the RM.
>
> I don't agree. It doesn't depend on the RM. The RM doesn't decide about
> policy compliance.
Non-compliance with policy is a serious bug. A serious-severity bug is
ordinarily a release critical issue, but the RM can say "this bug is not
release critical" whilst leaving the severity of the bug as serious.
I love overloaded nomenclature.
- Matt
Colin Watson
> Anyhow, how does someone file a bug against all these packages at once.
> All packages with this problem build-dep on gnustep-make.
Out of 26 of your bugs regarding this problem which were still open by
the time I got round to them on the release-critical bug list, I found a
full 19 to be completely invalid, and tagged them fixed accordingly. I
believe that Matthias Klose has also closed some of your bugs from this
mass-filing.
It is quite obvious that you didn't do even minimal testing before this
mass-filing. For every one of your bugs, I installed the package, looked
for a command in /usr/bin or /usr/games, then tried running that command
outside a GNUstep environment. Sometimes I also played around with the
program for a bit to make sure it wasn't totally insane outside a
GNUstep environment. In 19 of those cases, the package worked perfectly
well without any kind of helper program or need to manually source a
shell script or whatever. This was basic testing, and the bare minimum I
would expect from somebody reporting over two dozen RC bugs. It appears
that you didn't bother. If you somehow did, then you should have
provided more detail about the problem; your bug reports were clearly
all created from the same template, and contained no other useful
information.
This episode wasted an hour of my time that I could and would have spent
doing something more productive. I'm sure it also wasted the time of
quite a number of other people, as it made it more difficult to see what
was important on the release-critical bug list. Next time you
contemplate mass-filing bugs, especially at high severities, remember
that the BTS is a project resource, and that it is your job to use it
responsibly, not other people's job to clean up after you.