Enrico Weigelt | 27 Aug 2010 00:11
Picon

Re: FYI: paper on the oss-qm project

* Enrico Weigelt <weigelt <at> metux.de> wrote:
> 
> Hi folks,
> 
> just in case anybody's interested: 
> 
> I've written a little paper on the OSS-QM project, which aims to
> provide fixed sourcetrees of lots of packages+versions as quick
> as possible and so offload common QM works from individual distros:
> 
> http://www.metux.de/download/oss-qm-project-2010050101.pdf

Meanwhile I've set up an sf.net site for it:

https://sourceforge.net/p/oss-qm/home/

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

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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
(Continue reading)

Enrico Weigelt | 27 Aug 2010 00:33
Picon

Rules for distro-friendly packages


Hi folks,

I've written down a buch of rules which should make distro
maintainer's life much easier:

http://www.metux.de/index.php/de/component/content/article/57.html

Feel free to comment about it.

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

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

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Ken Moffat | 27 Aug 2010 01:41

Re: Rules for distro-friendly packages

On Fri, Aug 27, 2010 at 12:33:43AM +0200, Enrico Weigelt wrote:
> 
> Hi folks,
> 
> 
> I've written down a buch of rules which should make distro
> maintainer's life much easier:
> 
> http://www.metux.de/index.php/de/component/content/article/57.html
> 
> Feel free to comment about it.
> 
 On a quick look, I can't see the point of these rules.  So, I have
to ask - "What is/are the problem(s) you are trying to solve ?"

 In particular, I don't understand this one under canonic(al) package
name -

 It MUST change if there is an major branch break, so upcoming
 releases are incompatible and conflicting to previous releases.

 You seem to be saying that a new version will need a new package
name, not just a new major or minor version number ?

 Also, I'm unimpressed by -

 General-purpose libraries (in contrast to plugin libraries), MUST
 provide static and shared libraries as well. Exceptions to this MUST
 have very good reasons and be clearly stated in the proper places
 (eg. configure script output)
(Continue reading)

Enrico Weigelt | 27 Aug 2010 11:53
Picon

Re: Rules for distro-friendly packages

* Ken Moffat <zarniwhoop <at> ntlworld.com> wrote:

Hi,

>  On a quick look, I can't see the point of these rules.  So, I have
> to ask - "What is/are the problem(s) you are trying to solve ?"

this comes from my experiences and problems in package/distro 
maintenance over the last decade, which would have been 
prevented if the upstream did follow that rules ;-p

>  In particular, I don't understand this one under canonic(al) package
> name -

well, it has to be unique (to prevent conflicts with other packages)
and doesnt change arbitrarily. (for example it should not contain
any "-", etc)

>  It MUST change if there is an major branch break, so upcoming
>  releases are incompatible and conflicting to previous releases.

That's an very interesting inssue. For really major interface breaks
(in fact: new interfaces), such as on glib-1.x -> glib-2.x I'd 
really suggest adding the generation number to the name, eg. calling
it "glib2" (although didnt state it in the document yet).

In general, interfaces should never break backwards API compatibility,
better create a new interface and leave alone the old one ;-p

>  My interests are desktop packages - I'd much rather have a
(Continue reading)

Stef Bon | 30 Aug 2010 21:20
Picon

Re: automounting cdrom drives (Udev question)

  On 06/27/2010 07:23 AM, Nathan Coulson wrote:
> I was doing some research into automounting, and I am trying to find
> the glue that can automatically mount a cdrom drive when inserted, and
> unmount/eject it when the eject button is pressed.
>
> udevadm monitor  does not show anything interesting when I hit the
> eject button, nor when a cd is inserted, so I have a hunch that it'll
> take more then udev.
>
> I heard that hal could do that (which has been depreciated, and
> replaced with devkit-disks), but I was not finding much information on
> how devkit works.  It 'feels' like a reporting program, requiring
> another program to mount the disks.
>
> Note: So far, just researching.  I was hoping to avoid PAM, which is
> one of the dependencies down the chain.
>
>
>
I found your message. A little late, but I'm working on a construction
to offer the user userfriendly access to all kinds of resources, local
like CDrom, what you're looking for, and USB devices and ATA harddisks, and
remote like SMB shares.

Look at :

http://linux.bononline.nl/projects/mount.md5key.new/

It creates a directory in the userhomedirectory offering
directories like
(Continue reading)


Gmane