headers
brian m. carlson | 1 Jan 2012 01:30
Gravatar

Re: from / to /usr/: a summary

On Sat, Dec 31, 2011 at 08:19:47PM +0000, Lars Wirzenius wrote:
> If the admin has not changed the config, dpkg and ucf will happily
> replace the old config with the new one, no questions asked, even
> when the config is in /etc. So no change there.

Right.  But if the sysadmin customizes any part of that configuration—
even something completely unrelated—which is very likely, then he or she
will be prompted.  So if the defaults are fine, then the defaults are
likely to be fine in the future.  If the defaults are not fine, which
often they are not, then the sysadmin will be prompted.

--

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Permalink | Reply | 1 comment |
headers
Paul Wise | 1 Jan 2012 01:39
Picon
Favicon
Gravatar

Re: from / to /usr/: a summary

On Sun, Jan 1, 2012 at 8:30 AM, brian m. carlson wrote:

> Right.  But if the sysadmin customizes any part of that configuration—
> even something completely unrelated—which is very likely, then he or she
> will be prompted.  So if the defaults are fine, then the defaults are
> likely to be fine in the future.  If the defaults are not fine, which
> often they are not, then the sysadmin will be prompted.

This is where Config::Model comes into play:

http://wiki.debian.org/PackageConfigUpgrade

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Permalink | Reply | 0 comments |
headers
Thomas Goirand | 1 Jan 2012 07:32
Picon

Re: from / to /usr/: a summary

On 12/31/2011 11:54 AM, Josh Triplett wrote:
> Almost all of those bug reports went away once udev moved
> the default location of distro-installed rules to /lib/udev/rules.d
> rather than /etc/udev/rules.d.
>   
Do you mean it went away, because in /usr/udev/rules.d it's not in
/etc, which meaningfully says "do not edit me, I'm not a conf file",
which leads to admins having less issues (because refraining from
hacking around)?

By the way, .rpmnew files really sux indeed! :)

Thomas
Permalink | Reply | 0 comments |
headers
Thomas Goirand | 1 Jan 2012 07:36
Picon

Re: from / to /usr/: a summary

On 01/01/2012 01:49 AM, brian m. carlson wrote:
> So the only sane thing to do is not change
> the default, ever.
>   
The other sane way is to mark files not in /etc as conffiles.
It semantically sux a bit, but if we have no choice because
of upstream decisions (which we don't have enough time to
fix), then that might be a way...

Thomas
Permalink | Reply | 4 comments |
headers
Russ Allbery | 1 Jan 2012 08:11
Picon
Favicon

Re: from / to /usr/: a summary

Thomas Goirand <thomas <at> goirand.fr> writes:
> On 01/01/2012 01:49 AM, brian m. carlson wrote:

>> So the only sane thing to do is not change the default, ever.

> The other sane way is to mark files not in /etc as conffiles.  It
> semantically sux a bit, but if we have no choice because of upstream
> decisions (which we don't have enough time to fix), then that might be a
> way...

That doesn't help unless you expect sysadmins to change them (unchanged
conffiles are quietly updated just like any other package file), at which
point it becomes an FHS violation.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>
Permalink | Reply | 3 comments |
headers
Chow Loong Jin | 1 Jan 2012 09:21
Favicon
Gravatar

Bug#653894: ITP: mediainfo -- MediaInfo supplies information about a video or audio file

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin <hyperair <at> ubuntu.com>

* Package name    : mediainfo
  Version         : 0.7.52
  Upstream Author : Info <at> MediaArea.net
* URL             : http://mediainfo.sf.net
* License         : LGPL
  Programming Lang: C++
  Description     : MediaInfo supplies information about a video or audio file

MediaInfo supplies technical and tag information about a video or audio file
.
What information can I get from MediaInfo?
General: title, author, director, album, track number, date, duration...
Video: codec, aspect, fps, bitrate...
Audio: codec, sample rate, channels, language, bitrate...
Text: language of subtitle
Chapters: number of chapters, list of chapters
.
What format (container) does MediaInfo support?
Video: MKV, OGM, AVI, DivX, WMV, QuickTime, Real, MPEG-1, MPEG-2,
MPEG-4, DVD (VOB)...
(Codecs: DivX, XviD, MSMPEG4, ASP, H.264, AVC...)
Audio: OGG, MP3, WAV, RA, AC3, DTS, AAC, M4A, AU, AIFF...
Subtitles: SRT, SSA, ASS, SAMI...
.
This package includes the command line interface
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Goirand | 1 Jan 2012 10:14
Picon
Favicon

Re: from / to /usr/: a summary

On 01/01/2012 03:11 PM, Russ Allbery wrote:
> Thomas Goirand <thomas <at> goirand.fr> writes:
>   
>> On 01/01/2012 01:49 AM, brian m. carlson wrote:
>>     
>   
>>> So the only sane thing to do is not change the default, ever.
>>>       
>   
>> The other sane way is to mark files not in /etc as conffiles.  It
>> semantically sux a bit, but if we have no choice because of upstream
>> decisions (which we don't have enough time to fix), then that might be a
>> way...
>>     
> That doesn't help unless you expect sysadmins to change them (unchanged
> conffiles are quietly updated just like any other package file), at which
> point it becomes an FHS violation.
>   
Which is why I wrote "semantically sux a bit" (it's another way to say
there's
a FHS violation ...). But my understanding is that we have no choice
considering the path upstream took.

I'd like to know: is it a normal thing to edit these files in
/usr/lib/udev/rules.d
(or, any other file that udev will use and which will be stored in /usr)?
Or should we expect that *never* anyone will touch them (eg: there's never
a real valid reason to edit them)?

Thomas
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernhard R. Link | 1 Jan 2012 12:57
Picon
Favicon

Re: from / to /usr/: a summary

* Russ Allbery <rra <at> debian.org> [111231 18:41]:
> "Bernhard R. Link" <brlink <at> debian.org> writes:
>
> > My experience is rather that people usually stick to their core packages
> > as personal property and won't except patches to make them more well
> > behaved.
>
> That experience aside, we're not talking about patches here, assuming
> Marco's description of the situation is correct.  We're talking about a
> full-blown fork and a need for a new udev upstream.  You don't need to
> send patches to anyone for that; you need to set up a Git repository, a
> web page, a development mailing list, some infrastructure around how
> you're going to maintain the software, and start doing regular releases,
> and then see about getting Debian to switch upstreams.
>
> > If people maintain some core piece of software and want to decide what
> > the package looks like, listen to what other people want.
>
> This isn't about the package.  It's about the *software*, the part that we
> generally use from upstream as much as possible because asking people to
> be both upstream and the Debian package maintainer is generally too much
> work for one person or even a small packaging team.

If the maintainer refuses patches and only wants to fix brokeness if
someone does a full blown upstream fork then this is a maintainer issue.

        Bernhard R. Link
Permalink | Reply | 4 comments |
headers
Bernhard R. Link | 1 Jan 2012 13:02
Picon
Favicon

Re: from / to /usr/: a summary

* Josselin Mouette <joss <at> debian.org> [111231 10:54]:
> Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit : 
> > If people maintain some core piece of software and want to decide what
> > the package looks like, listen to what other people want.
> > If you want to use "too much work" as excuse, then file a RFA.
>
> Because it’s well-known that filing RFAs will magically generate
> competent maintainers with a lot of time in their hands.

Spare your sarcasm, please.

While a RFA will not magically make people appear magically, one at
least makes clear that one would accept help.

Even there it is of course possible to refuse help as "incompotent",
just as refusing patches by requiring a full upstream fork.

But you cannot combine a "I'm the only one knowing how to handle the
package" with "There is not enough manpower for your request, so do not
dare to say that the current situation is broken".

        Bernhard R. Link

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/20120101120229.GC3185 <at> server.brlink.eu
Permalink | Reply | 1 comment |
headers
Toni Mueller | 1 Jan 2012 13:01
Picon
Favicon

Re: from / to /usr/: a summary

On 12/21/2011 11:55 AM, Russell Coker wrote:
> Nowadays 100G disks are small by laptop standards and for desktops 1TB is 
> about the smallest that anyone would buy.

Focussing on the desktop is the core of this - imho - misguided idea.
I'd still like to be able have a small, self-contained, Debian that I
can run on about anything. /usr is where all the real bloat (Gnome etc.)
lies, which may or may not be available, and if you eg. consider your
favourite phone storage, that's 512MB internally, or similar, with /home
presumably on an external storage (SD card).

> Things have changed a lot since the FSSTD first came out.

Indeed. Nowadays, we should support a much wider range of devices, not
just computers the size of refrigerators.

--

-- 
Kind regards,
--Toni++
Permalink | Reply | 3 comments |

Gmane