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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 03-21-2008, 02:25 AM
"Tom "spot" Callaway"
 
Default one more draft

I've added another draft to the todo list:
http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv

I doubt we'll get to it on Tuesday, but we'll get to it eventually.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-23-2008, 03:26 PM
Ville Skyttä
 
Default one more draft

On Friday 21 March 2008, Tom "spot" Callaway wrote:
> I've added another draft to the todo list:
> http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
>
> I doubt we'll get to it on Tuesday, but we'll get to it eventually.

If this passes, it needs a statement what to do with packages that already
use /srv in a way that conflicts with the draft. /srv/foo is typically data,
potentially lots and lots of it, so auto-migrations are practically out of
the question and manual ones are possibly nontrivial amounts of admin work.
Therefore I'd suggest letting them stay as is.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-23-2008, 05:02 PM
Axel Thimm
 
Default one more draft

On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
> On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > I've added another draft to the todo list:
> > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> >
> > I doubt we'll get to it on Tuesday, but we'll get to it eventually.
>
> If this passes, it needs a statement what to do with packages that already
> use /srv in a way that conflicts with the draft. /srv/foo is typically data,
> potentially lots and lots of it, so auto-migrations are practically out of
> the question and manual ones are possibly nontrivial amounts of admin work.
> Therefore I'd suggest letting them stay as is.

Which packages are these? Maybe they can check whether they are being
upgraded (from a package evr polluting /srv) or freshly installed. In the
latter case they should behave as every other package, e.g. not assume
anything about /srv.
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-23-2008, 07:20 PM
Ville Skyttä
 
Default one more draft

On Sunday 23 March 2008, Axel Thimm wrote:
> On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
> > On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > > I've added another draft to the todo list:
> > > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> > >
> > > I doubt we'll get to it on Tuesday, but we'll get to it eventually.
> >
> > If this passes, it needs a statement what to do with packages that
> > already use /srv in a way that conflicts with the draft. /srv/foo is
> > typically data, potentially lots and lots of it, so auto-migrations are
> > practically out of the question and manual ones are possibly nontrivial
> > amounts of admin work. Therefore I'd suggest letting them stay as is.
>
> Which packages are these?

vdr (maintained by yours truly) is one. There's easily tens or hundreds of
gigabytes of DVB recordings in /srv/vdr.

> Maybe they can check whether they are being
> upgraded (from a package evr polluting /srv) or freshly installed. In the
> latter case they should behave as every other package, e.g. not assume
> anything about /srv.

I suppose that's possible (didn't think of that, thanks), but will lead to
more or less fragile config file modifications in scriptlets. I'm leaning on
the side of calling these modifications uglier than just leaving the data
where it is in /srv especially because there's no certainty how this issue
will be treated in the future (the draft contains things like "unclear"
and "At this time").

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-23-2008, 07:48 PM
Axel Thimm
 
Default one more draft

On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
> On Sunday 23 March 2008, Axel Thimm wrote:
> > On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
> > > On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > > > I've added another draft to the todo list:
> > > > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv

> > > If this passes, it needs a statement what to do with packages that
> > > already use /srv in a way that conflicts with the draft. /srv/foo is
> > > typically data, potentially lots and lots of it, so auto-migrations are
> > > practically out of the question and manual ones are possibly nontrivial
> > > amounts of admin work. Therefore I'd suggest letting them stay as is.
> >
> > Which packages are these?
>
> vdr (maintained by yours truly) is one. There's easily tens or hundreds of
> gigabytes of DVB recordings in /srv/vdr.
>
> > Maybe they can check whether they are being upgraded (from a
> > package evr polluting /srv) or freshly installed. In the latter
> > case they should behave as every other package, e.g. not assume
> > anything about /srv.
>
> I suppose that's possible (didn't think of that, thanks), but will
> lead to more or less fragile config file modifications in
> scriptlets.

Why fragile? It either checks whether a previous vdr config told vdr
to put files there or looks whether /srv/vdr exists.

> I'm leaning on the side of calling these modifications uglier than
> just leaving the data where it is in /srv

As said if the data is there leave it there. If it is a new install
then have the user decide where he needs his data being placed in. So
you'll keep legacy users happy and a clean /srv in new
installs. Wiring in /srv/vdr forever would break any site using
/srv/<domain>/<service> setups (like mine .

> especially because there's no certainty how this issue will be
> treated in the future (the draft contains things like "unclear" and
> "At this time").

These attributes including the "poor wording" are just spot's POV on
the FHS' stand on /srv. In fact the /srv hierarchy has been beaten to
death in various groups, be it FHS or LSB and the outcome is always
that no standard can or should dictate what the setup should look like
as it already diverges in typical single and multiple instance setups.

IOW there will never be any further detailed specification from any
standard on how to have users treat their data layout. But maybe some
further rationale should be added to the FHS to make readers
understand why there should be no vendor given contraints on the
layout. Changes in the FHS are real slow, though (see my libexec
standardization attempts a long while back).
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-24-2008, 07:40 AM
Ville Skyttä
 
Default one more draft

On Sunday 23 March 2008, Axel Thimm wrote:
> On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
>
> > I suppose that's possible (didn't think of that, thanks), but will
> > lead to more or less fragile config file modifications in
> > scriptlets.
>
> Why fragile? It either checks whether a previous vdr config told vdr
> to put files there or looks whether /srv/vdr exists.

Previous config doesn't tell vdr anything, it uses compile time defaults,
ditto would most likely the new one. Deciding something based on
whether /srv/vdr exists is exactly the kind of fragility I mean. As is the
fact that we don't have a tool that could be reliably used to modify sourced
shell scripts (/etc/sysconfig/vdr) in the first place. Etc. There's a reason
why doing things like this is frowned upon.

> > I'm leaning on the side of calling these modifications uglier than
> > just leaving the data where it is in /srv
>
> As said if the data is there leave it there.

Just in case it wasn't clear, I meant leaving not only the data there but the
package and its dir ownerships as is too.

> If it is a new install
> then have the user decide where he needs his data being placed in.

They can already configure it in /etc/sysconfig/vdr. Making it mandatory to
configure it manually is not something I'm going to inflict on users, stuff
needs to work out of the box to the extent possible. Users already need to
create channels.conf manually, that's bad enough.

> > especially because there's no certainty how this issue will be
> > treated in the future (the draft contains things like "unclear" and
> > "At this time").
>
> These attributes including the "poor wording" are just spot's POV on
> the FHS' stand on /srv.

Sounds like the draft needs some work.

In addition to the above, I think "don't touch anything in /srv but feel free
to make default configs tell apps to store data somewhere there" (which is
how I read the draft in a nutshell) doesn't sound good. For typical cases,
the only practical difference to creating and owning the data dir(s) there
would be that users would have to create them manually with the correct
ownerships and permissions.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Mon Mar 24 12:30:01 2008
Return-path: <fedora-list-bounces@redhat.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Mon, 24 Mar 2008 10:44:25 +0200
Received: from hormel1.redhat.com ([209.132.177.33] helo=hormel.redhat.com)
by s2.java-tips.org with esmtp (Exim 4.68)
(envelope-from <fedora-list-bounces@redhat.com>)
id 1JdiI5-0003Tf-Lk
for tom@linux-archive.org; Mon, 24 Mar 2008 10:44:25 +0200
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP id B0FCC618780;
Mon, 24 Mar 2008 04:44:17 -0400 (EDT)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
m2O8iGW9002896 for <fedora-list@listman.util.phx.redhat.com>;
Mon, 24 Mar 2008 04:44:16 -0400
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2O8iF7d026041
for <fedora-list@redhat.com>; Mon, 24 Mar 2008 04:44:15 -0400
Received: from mars.math-info.univ-paris5.fr (mars.math-info.univ-paris5.fr
[193.48.200.18])
by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m2O8hfAX028950
for <fedora-list@redhat.com>; Mon, 24 Mar 2008 04:43:41 -0400
Received: from [127.0.0.1] (mars.math-info.univ-paris5.fr [127.0.0.1])
by mars.math-info.univ-paris5.fr (8.14.1/jtpda-5.4) with ESMTP id
m2O8hdcd021110
for <fedora-list@redhat.com>; Mon, 24 Mar 2008 09:43:40 +0100
Message-ID: <47E769BB.90803@math-info.univ-paris5.fr>
Date: Mon, 24 Mar 2008 09:43:39 +0100
From: =?ISO-8859-1?Q?Fran�s_Patte? <francois.patte@math-info.univ-paris5.fr>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: fedora-list@redhat.com
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Miltered: at mars.math-info.univ-paris5.fr with ID 47E769BB.000 by Joe's
j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Score: MSGID : 47E769BB.000 on mars.math-info.univ-paris5.fr :
j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-RedHat-Spam-Score: -0.096
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254
X-Scanned-By: MIMEDefang 2.63 on 172.16.48.32
X-loop: fedora-list@redhat.com
Subject: /dev/dm-x????
X-BeenThere: fedora-list@redhat.com
X-Mailman-Version: 2.1.5
Precedence: junk
Reply-To: For users of Fedora <fedora-list@redhat.com>
List-Id: For users of Fedora <fedora-list.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-list>,
<mailto:fedora-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/fedora-list>
List-Post: <mailto:fedora-list@redhat.com>
List-Help: <mailto:fedora-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-list>,
<mailto:fedora-list-request@redhat.com?subject=subscribe>
Sender: fedora-list-bounces@redhat.com
Errors-To: fedora-list-bounces@redhat.com
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bonjour,

I have just used the command fidsk -l in order to see what was my
partitionning system.

I discovered a lot of /dev/dm-x disks without any "valid partition table"

But, if I mount them (mount /dev/dm-9 /mnt) they are mounted without any
problems and these discks are only the partitions allready mounted under
another name (this /dev/dm-9 is /home...)

What does this mean?

I am using lvm

Thanks for lights.
- --
Fran�s Patte
UFR de math�tiques et informatique
Universit�aris Descartes
45, rue des Saints P�s
F-75270 Paris Cedex 06
T� +33 (0)1 44 55 35 61
http://www.math-info.univ-paris5.fr/~patte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH52m7dE6C2dhV2JURAl1nAJ99B7RPnGGTKlXDELgibP mA92LoeQCfUlIt
5Y1oJjpawdCrST//FYlWfIA=
=yRBC
-----END PGP SIGNATURE-----

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-24-2008, 09:07 AM
Axel Thimm
 
Default one more draft

On Mon, Mar 24, 2008 at 10:40:30AM +0200, Ville Skyttä wrote:
> On Sunday 23 March 2008, Axel Thimm wrote:
> > On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
> >
> > > I suppose that's possible (didn't think of that, thanks), but will
> > > lead to more or less fragile config file modifications in
> > > scriptlets.
> >
> > Why fragile? It either checks whether a previous vdr config told vdr
> > to put files there or looks whether /srv/vdr exists.
>
> Previous config doesn't tell vdr anything, it uses compile time defaults,

> > If it is a new install then have the user decide where he needs
> > his data being placed in.
>
> They can already configure it in /etc/sysconfig/vdr.

That's what I mean. Whatever the hardwired defaults at compile time
the /etc/sysconfig/vdr takes precedence. So the package's scripts can
easily autoadjust to whatever situation. For correctness sake (imagine
someone calling vdr manually) the compile time defaults should be w/o
any /srv bits.

> > As said if the data is there leave it there.
>
> Just in case it wasn't clear, I meant leaving not only the data there but the
> package and its dir ownerships as is too.

But that would be wrong. One of the main FHS aspects is that a package
should not remove anything (e.g. not own anything) beneath /srv. And
that's what the draft also tried to map into the guidelines.

Just to reiterate: The /srv/vdr folder currently breaks all
/srv/<domain> setups.
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-24-2008, 02:23 PM
Ville Skyttä
 
Default one more draft

On Monday 24 March 2008, Axel Thimm wrote:

> Whatever the hardwired defaults at compile time
> the /etc/sysconfig/vdr takes precedence. So the package's scripts can
> easily autoadjust to whatever situation.

Good to hear you know better; I expect to see code to back that up if the
draft passes with a mandate to change the dirs

> But that would be wrong. One of the main FHS aspects is that a package [...]

We already do some things "wrong" wrt the FHS, for example /etc/rc.d/init.d
and /usr/libexec. I'm not aware of much movement in getting those fixed
although unlike /srv, they don't deal directly with user data and could
conceivably be easier and safer to fix. (Right, this is not a reason to
allow more wrongdoings, but they're in the same boat of kinda "this is how
things have been traditionally done, and we don't think it's worth the
trouble to change these particular cases".)

> Just to reiterate: The /srv/vdr folder currently breaks all
> /srv/<domain> setups.

Sure, if you happen to have a <domain> dir called vdr there for some other
purpose. Similar things could be said about /var/lib/vdr or /var/spool/vdr.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 06:00 PM
Axel Thimm
 
Default one more draft

On Mon, Mar 24, 2008 at 05:23:00PM +0200, Ville Skyttä wrote:
> On Monday 24 March 2008, Axel Thimm wrote:
> > Whatever the hardwired defaults at compile time the
> > /etc/sysconfig/vdr takes precedence. So the package's scripts can
> > easily autoadjust to whatever situation.
>
> Good to hear you know better; I expect to see code to back that up if the
> draft passes with a mandate to change the dirs

Sure, that's what the FPC's jobs is: to go hunt all packages and fix
them. Good that I'm not a member anymore

Of course, the more serious answer is that this is the packager's job.

> > But that would be wrong. One of the main FHS aspects is that a
> > package [...]
>
> We already do some things "wrong" wrt the FHS, for example
> /etc/rc.d/init.d and /usr/libexec.

So that justifies breaking even more?

> I'm not aware of much movement in getting those fixed

Well, check the todo lists and your IRC logs, I was trying to get the
libexec stuff addressed and some steps where done, including an
official submission for a change in the FHS, but it now needs a new
(Fedora) driver to get this pushed further.

So things are done to get Fedora in sync with FHS. I'm not aware what
the /etc/rc.d/init.d issues are to comment on that, but if there's a
deviation the FPC should look at it (if it hasn't done so already).

> > Just to reiterate: The /srv/vdr folder currently breaks all
> > /srv/<domain> setups.
>
> Sure, if you happen to have a <domain> dir called vdr there for some other
> purpose.

Of if my scripts run over these folders and suddenly assume I'm
hosting a "vdr" domain. There are reasons the FHS explicitely forbids
vendors to mess in there.

> Similar things could be said about /var/lib/vdr or /var/spool/vdr.

No, the (limited) freedom of choice in the layout to the user/admin is
solely under /srv (and /opt, /usr/local).
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-26-2008, 04:45 AM
Ville Skyttä
 
Default one more draft

On Tuesday 25 March 2008, Axel Thimm wrote:
> On Mon, Mar 24, 2008 at 05:23:00PM +0200, Ville Skyttä wrote:
> > On Monday 24 March 2008, Axel Thimm wrote:
> > > Whatever the hardwired defaults at compile time the
> > > /etc/sysconfig/vdr takes precedence. So the package's scripts can
> > > easily autoadjust to whatever situation.
> >
> > Good to hear you know better; I expect to see code to back that up if the
> > draft passes with a mandate to change the dirs
>
> Sure, that's what the FPC's jobs is: to go hunt all packages and fix
> them. Good that I'm not a member anymore

Eh. The FPC has not been claiming that this would be easy, you are.

> Of course, the more serious answer is that this is the packager's job.

Well, I say it's not feasible in the case of vdr, and that's not something I
can prove; spending time on it and not coming up with a feasible solution is
not a proof it can't be done, it's just silly waste of my time. On the other
hand, you are parroting it's easy, and if it is, it should be easy for you to
prove as well.

> > We already do some things "wrong" wrt the FHS, for example
> > /etc/rc.d/init.d and /usr/libexec.
>
> So that justifies breaking even more?

Did you read the mail you're replying to? From the same paragraph as my
sentence above: "Right, this is not a reason to allow more wrongdoings
[...]".

> > Similar things could be said about /var/lib/vdr or /var/spool/vdr.
>
> No, the (limited) freedom of choice in the layout to the user/admin is
> solely under /srv (and /opt, /usr/local).

Please cite or provide exact pointers to where this is documented.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 10:29 AM.

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